visual designer capabilities

[jcfuller]

Just a heads up on visual designer capabilities.

I have been nesting label controls for close to 20 years (see attached) using Borland's C/C++ 5.0 dialog editor, and most recently KetilO's Resource Editor.

Of the three commercial offerings I've tried( PowerDev 2,Firefly,PBForms) only PBForms performs as I expect.

I do not know if (ez.commercial) allows this. I did try with the free ddt designer and it appears it may work (with layers??) but is not intuitive.

I know all the commercial products offer many advanced features and intend to make dialog/window creation easier but for the simple basic desgin capabilities I require they fail.


James

[José Roca]

Not all fail. This one has been made using Phoenix.

[Edwin Knoppert]

PwrDev can do child forms, and yes.. nested if you like.
Unf. the placement of the childforms is not by visual design.

So if you have a main form, other forms can be loaded as child but only by code (single line).
A childform can load another childform.
The development of the childform(s) is done as a normal form, via the designer.

For PwrDev it would be easy to write a placeholder so you can load the childform in a form.
Though actual editting is a bit difficult, the original form maybe under development (open) and therefore this feature is just not added.

Maybe i prepare the placeholder but without modify options.
Yes, unfinished business, i agree..

Here is a snapshot, poor example though

https://www.hellobasic.com/images/multiform.png

[Paul Squires]

z-order of Label/Static controls in FireFly 2 are not set correctly in the designer. However, there is no problem using child forms to simulate the effect. In addition, you can achieve the ffect using Labels but you would need to use SetWindowPos to arrange the Label ordering correctly via code at run time. This will all be fixed in FireFly 3. This is the first report in four years of someone attempting to nest mulitple Labels on top of each using FireFly. Thanks James

[Chris Boss]

No problem with EZGUI 4.0.

The key is defining the Tab Order #.

By default the designer impliments Tab order in the order the controls are created (1,2,3, ...). Tab order is the same as zorder with EZGUI.

By editing the tab order #'s for each label, you can force them in the correct zorder.

[Chris Boss]

Even my freeware DDT designers can do this.

Again, you have to set the Tab order #'s correctly for each control.

For example, I create the larger label first and then set its tab order # to 100.

I create the second smaller label and set its tab order # to 99.

Then I create the text control and buttons (which by default get tab #'s 3 and 4) and all done.

[Chris Boss]

EZGUI tools simply let windows generate the zorder, by the order the controls are created.

To make sure the controls you add to forms are in the correct order, it does the following when generating code ( as well as in Design mode):

Controls are ordered as follows:

(1) By layer number (layers 1,2, 3, etc. and then layer 0 last)
(2) By Tab order number (1,2,3)
(3) If two controls have the same tab order number, then the order in which they were created in the designer.

[Paul Squires]

Just to clarify: FireFly can create the stacked Labels by setting the Tab Order in the desired order. The problem in FireFly is that it is not visually represented in the designer when the change is made. The resulting compiled EXE works perfectly. Also, only Labels have this problem. All other controls zorders work fine in the designer and in the compiled exe.

[Paul Squires]

I remembered why I designed FireFly to keep Labels from being displayed like other controls. Users of FireFly 1 told me that they found it inconvenient to have Labels placed close to other controls and have portions of them display (or bleed) into an adjacent control.

For example, say you have a Label that describes the TextBox immediately below it. The Label, if not resized perfectly, could overlay parts of the TextBox causing the GUI effect to be horrible. FireFly ensures that the Label will display behind the TextBox (well, at the portions of the Label that doesn't have text that you want the user to see). Whether this approach is right or wrong, it has proved to be very convenient in the majority of applications that I have built. In James' example however it does cause problems.

[Dominic Mitchell]

This sort of thing is natural in Phoenix. You don't have to worry about z-order.
You just draw them the way you want them to appear. The option to set z-order is there
coupled with the ability to undo or redo z-order settings.

[Patrice Terrier]

That kind of problem is so easy to solve with the native SDK API SetWindowpos

You can also use the EnumChildWindows with an appropriate callback to change the current z-order.


.

[Chris Boss]

I think what James is concerned about is being able to do it Visually in the designer.

The whole idea of a Visual Designer is to be able to visualize how your program will look, before generating code.

Any Visual Designer which uses the natural Zorder of controls by the order they are created should be able to do what he wants. If the zorder is the same as the order the are created in the designer, then simply create the textbox and buttons controls first, then the smaller label control and finally the larger. That will put them in the proper zorder.

[Michael Mattias]

FWIW, SetWindowPos() can be used to change the Z-order "on the fly"