PF>
  > JdeBP> Guidelines 3.2 apparently supports IBM VisualAge
  > JdeBP> C++ 3.01 for OS/2 and Borland C++ 4.5 for DOS.
  > JdeBP> How much more current can you get ?
  >
  > It's late.
PF>

  Let's see now.  IBM VisualAge C++ 3.00 was released in May/June, and
  JBA Guidelines 3.2, which supports it, was released in October.

  Considering the size of the full package (not just the free base pack,
  but also all of the add-ons and whatnot that are listed as optional
  extras), I'd say that four months is quite good going for supporting a
  whole new C++ compiler.

  And don't claim that development should have started with the beta.
  Having used the beta of IBM VisualAge C++ 3.00, I know from personal
  experience that no commercial applications should be developed with
  it.  (-:

  ( Humour aside, the beta of IBM VisualAge C++ 3.00 is different to the
    GA anyway.  There are differences in DLLs and libraries.   At the
    bare minimum, anything built on the beta would have to be completely
    rebuilt from scratch on the GA, and then checked carefully.  Even
    doing that on something the size of Guidelines would be a fairly
    large operation.  )

  So your claim is without foundation.

  And how much development effort do you think was drained away by
  having, at the same time, to add support for Borland C++ 4.5 on
  DOS+Windows (also new in Guidelines 3.2) ?

PF>
  >  JdeBP> VisualBuilder is specific to VisualAge C++ (if you want to talk
  >  JdeBP> about poor compiler support, *this* is the tool to pick upon)
  >
  > It comes with a C++ compiler that it is guaranteed to support.
PF>

  Double standards I see.  It's all right for VisualBuilder to only
  support *1* compiler, but Guidelines is castigated for not supporting
  *all* of them *right now*.

PF>
  >  JdeBP> was published) been able to obtain a copy of Prominaire Designer
  >  JdeBP> (which only generates C code, not C++ code like Guidelines).
  >
  > I take issue with that.  Guidelines,  although it requires
  > a C++ compiler, does not really generate C++ code -- sure,
  > you'll see the word 'class' in the header files,  but the
  > code that it generates for _you_ is not OO at all.
PF>

  The important consideration of an application builder, surely, is
  whether or not the final application is any good.  After all, the
  aforementioned VisualBuilder itself may be the bees-knees when it
  comes to O-O (it being written in SmallTalk), but it requires 32Mb of
  RAM to run.  Is "O-Oness" *really* a good measure of an application ?

  Nevertheless (returning to the original issue at hand), Guidelines 3.2
  does generate C++ code.  If you look at the generated output, you'll
  see code such as

       win.SetProperty(WPID_XPOS, 10) ;

  and

       str = win.GetPropString(WPID_TEXT) ;

  which is definitely not C code.

PF>
  > And Prominaire Designed _does_ generate C++ code
PF>

  Only if you shell out major money for it.  I was comparing like for
  like (the free Guidelines Base Pack against the free Prominare
  Designer "Lite").  Guidelines generates C++ code, whereas Prominaire
  only generates C code.

PF>
  > [...] but at least ICLUI support is a big step in the OO direction.
  >
  > One big plus about Designer is that you get 100% of the
  > source code (including custom controls) needed to compile
  > your program.
PF>

  More double standards, I see.  As someone who in the previous sentence
  goes on about using class libraries (it's called OpenClass these days,
  incidentally) rather than programming directly to the API because they
  are "O-O", you then go on to praise the custom controls of Prominaire
  Designer, which are not O-O in any way whatsoever.

  You'd have thought that they would be classes, but it turns out that a
  PD custom control is nothing more than a window procedure (the usual
  "direct to API" stuff, complete with massive switch statement), a
  procedure to register a window class that points to the window
  procedure, and a couple of housekeeping procedures that pass whopping
  great structures back and forth and that do little more than register
  all of the window style flags associated with the control, and allow
  PD to present a pretty list of checkboxes in a dialogue.

  Frankly, I won't be happy until I have a tool that allows one to write
  custom controls by deriving new classes ... SOM classes, of course.

  As for unavailability of source for the Guidelines runtime, I suspect
  that you simply haven't offered enough money.  (-:

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.00