IceDesign GUI designer

[ShadowStorm]

Very good all that thank you

I will put my reviews one after the other here.

For the Gadgets, why not make an option to either name the gadgets like you do here (not by default but to be activated), or name them by their normal name (by default).

For example for a button, it will be Button_1.
It's much easier that way to find your way around, to know what a gadget is, that's my opinion anyway!

Then the _1_1, or like _2_4, etc, same, not clear at all, explain me what it means?
There too I think it might be necessary to review?

could they please have a menue to copy the code that has been generated in the editor, so I copy the code and test it in PB

when one or more gadgets are selected, it is useless I think to display the items to add a menue etc, it should appear only if I click on the window and not on a gadget!

when I right-click on a gadget that is not already selected, it should be selected and the menue should appear, right?

when I resize a ScrollAreaGadget, the grid is not complete.

when I create a CanvasContainerGadget in the ScrollAreaGadget, this one is not in the ScrollAreaGadget but in fact it disappears and is put on the window!
but when I test it's ok, in fact it's a defect of the program display.
On the other hand when I test even in PB, the gadgets in the canvas do not react.

[ChrisR]

Thanks for your feedback

I had chosen the indexed number, thinking that #Button_1 would be renamed before copying to, e.g.: #Button_OK, #Button_Cancel...
Thus when copying, it keeps part of its original name, the other properties keep the same values.
This results in #Button_OK_1, #Button_Cancel_1... rather than #Button_2, #Button_3. It seems easier this way to identify the copied gadgets

But, It could perhaps be an option ex: keep original name indexed.
At the same time, there are already many options, it would be good if there were not too many to keep IceDesign simple.

[ChrisR]

when I resize a ScrollAreaGadget, the grid is not complete.

The grid drawn depends on the internal area (inner width, inner height).
It is not automatically resized when you enlarge or shrink the ScrollArea.
Is it ok like this ? I could eventually have bigger Inner Width, Inner Height default values.

[ChrisR]

when I create a CanvasContainerGadget in the ScrollAreaGadget, this one is not in the ScrollAreaGadget but in fact it disappears and is put on the window!
but when I test it's ok, in fact it's a defect of the program display.
On the other hand when I test even in PB, the gadgets in the canvas do not react.

Are you sure you opened the ScrollAreaGadget (Open Container Button) before creating the CanvasContainerGadget ?
Otherwise its parent remains the window and not the ScrollArea.


I just got this message in red:
You cannot make another post so soon after your last.
A good thing to fight spammers

[ShadowStorm]

when I resize a ScrollAreaGadget, the grid is not complete.

The grid drawn depends on the internal area (inner width, inner height).
It is not automatically resized when you enlarge or shrink the ScrollArea.
Is it ok like this ? I could eventually have bigger Inner Width, Inner Height default values.

why don't you resize it?
or maybe there are some things I forgot to fill in.
Yes, there are some things I forgot to fill in!

The behavior seems normal in fact.

On the other hand if I change the values of interior size, there it should update when the string pers the focus for example.
Here it is not updated unless I change the size of the scroll on the window or in the strings, for me this does not seem normal.

[ShadowStorm]

We can't cut a container, and if we ask to copy or clone then the gadgets inside are not, here not normal either!

[ShadowStorm]

when I create a CanvasContainerGadget in the ScrollAreaGadget, this one is not in the ScrollAreaGadget but in fact it disappears and is put on the window!
but when I test it's ok, in fact it's a defect of the program display.
On the other hand when I test even in PB, the gadgets in the canvas do not react.

Are you sure you opened the ScrollAreaGadget (Open Container Button) before creating the CanvasContainerGadget ?
Otherwise its parent remains the window and not the ScrollArea.

Ah yes, ah yes we must be careful ^^
do you think it would be possible to have a warning message?
for example if I create a gadget on a not opened container, a message appears and informs that I try to create an object on a container (when I say container, it's general, srollarea, container, canvas container, etc) that is not opened.

So what do you do after ..... why not a message like:

"You are trying to create and insert a Gadget on the container "gadget name", however, it is not open!

Do you want to create and insert the Gadget on in the "gadget name" container or on the window?
Yes = on the container, no = on the window."

Or something like that?

[ChrisR]

On the other hand if I change the values of interior size, there it should update when the string pers the focus for example.
Here it is not updated unless I change the size of the scroll on the window or in the strings, for me this does not seem normal.

It's fixed.

We can't cut a container, and if we ask to copy or clone then the gadgets inside are not, here not normal either!

You have already made the request, I agree, it would be better but it is not so easy to do.
We need a first loop to select all the children and the children's children... and a second hierarchical loop to create the copy of the selected gadgets with opening and closing of the containers...
That's why I limited it, for now, to only Copy/Clone and only the container without its children
But hey, it's written in my todo.

[ChrisR]

Ah yes, ah yes we must be careful ^^
Do you think it would be possible to have a warning message?

Yes, a message could be good, I will look at

Edit: However, via drag'n drop, it could be in a container itself child of another container...
and to create a gadget, the container(s) must be open, in my model.

Better to inform the user with a message such as:

The Container "#ScrollArea1" is Not Open, the Gadget will be Created in the Current Level. Continue ? Yes/Cancel

And if cancel, let the user open the level(s) to create the gadget in the right container.

[ShadowStorm]

Ah yes, ah yes we must be careful ^^
Do you think it would be possible to have a warning message?

Yes, a message could be good, I will look at

Edit: However, via drag'n drop, it could be in a container itself child of another container...
and to create a gadget, the container(s) must be open, in my model.

Better to inform the user with a message such as:

The Container "#ScrollArea1" is Not Open, the Gadget will be Created in the Current Level. Continue ? Yes/Cancel

And if cancel, let the user open the level(s) to create the gadget in the right container.

After several re-readings, yes I understood.
For me I think the most logical thing would be to open the concerned container where the gadget has been dragged?

I know, it's very very difficult this kind of thing.
You don't have to complicate your life too much.

Here to do what I proposed, I don't know the level of complexity, you already have to detect on which gadget the gadget was created, so I guess you have to open all the lower levels?

[ChrisR]

To try to be clear, better to explain how it works:
In IceDesign, each container has its own drawing area (Canvas).
These drawing areas are enabled or disabled when changing levels (or tabs in a Panel) with "Open Container" or "Close Container"
With some actions done, Close and Open the GadgetList(), BindGadget, Calculate OffSets and Max Sizes,...

I'm not in a flat model like EditorFactory with a single canvas in which it would be, I believe, quite easy to implement.

About the subject:
In my main hierarchical list(), I don't have any information other than Parent/Child to know the path to go from a level to another level in another branch.
And so, I can't do it, without knowing the path to follow.

That's why a message like this one, should do the trick:

Code: Select all

The Container "#ScrollArea1" is Not Open, the Gadget will be Created in the Current Level. Continue ? Yes/Cancel

After 2 or 3 messages, we know better that we have to open the right container before adding a Gadget

[ChrisR]

IceDesign has been updated in version 1.5.2

New features:

• Container constants are now drawn (eg below with #PB_ScrollArea_Center).
  However, they are redrawn, only if it does not contain other gadgets and if the container is closed.

• Add SplitterExt Module by chi to color the Splitters.

• Cut, copy, paste and clone Containers is available now. It includes the copy of all child gadgets.

• From the "Create Controls" list, you can drag'n drop the gadgets in any container even if it is not open or in another branch.
  The container will be automatically opened to be able to create the gadget inside.

• You can now freely select a Gadget or a Container in the window, without having to go through, open/close containers.

[Caronte3D]

Nice!

[VB6_to_PBx]

hi ChrisR ,
nice update , and thank you for continuing to upgrade your Designer !

i have 2 problems :

[1]= when i create a Window size of 1160x764 with #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_ScreenCentered
it really creates a 1170x774 size window, and even if i Save it , its still 1170x774 instead of 1160x764
it seems i can always use 1155x764 and it works ... but try 1160x764 and it changes or uses 1170x774 instead
even though it will sometimes showup in your Designer's Constants as 1160x764 , but its really 1170x774

it would be great if you could "fix" it to really use+save as a 1164x764 size

----------------------------

[2]= it also would be great that your Designer when 1st startup would remember
in Settings if i've chosen "only" these Window Constants : #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_ScreenCentered

as the Designer is now , everytime i 1st Start it up , the Window Constants are always these "
#PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_MaximizeGadget | #PB_Window_SizeGadget | #PB_Window_ScreenCentered

when i'd like it remember my Settings :
#PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_ScreenCentered
and only create the source code with : #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_ScreenCentered

[ChrisR]

Hi VB6_to_PBx,
For the 1st problem, I found the cause, it is a regression of the previous update v1.4.4 with the window constants drawn.
When I apply the new constants, the window size, including the borders (FrameCoordinate), does not change but the window inner size does.
I will fix it to keep the same window inner size, whatever the flags and redesign it accordingly.
Well seen

For the 2nd, I agree, it's a good idea to save the window constants in IceDesign.ini to restore them at the next use, I'll add it.

Thanks for the nice words, Caronte3D, VB6_to_PBx, I appreciate it, it is also a source of motivation to keep improving it, slowly, step by step
There are a lot of changes in the engine, I tested and retested but I hope I didn't break anything I didn't see,.
Chris