PureBasic Forums - English

ar-s wrote:For exemple, i'm making a 400x400 window
I put an image to make a background for my application
This image is same size as window size.

So it is impossible to add a gadget (string gadget for exemple) over the image. We have to grow window size (400x600 for exemple), then create a gadget below image, then put the new gadget on image then resize window 400x400.

Could you make creating gadget over an image in next Build ?

Yes, you can't draw a gadget over another gadget, except for 'container' gadgets (panel / container / scrollarea) and Frame3D.
But, if you disable the image gadget ['Disable' button in gadget properties] you can draw a button in top of it ! You can enable the image later. The 'disabled' state has no effect on the generated code.
Note that the button won't work ... You will have to add the #WS_CLIPSIBLINGS style to the imagegadget and redefine the Z order like in http://www.purebasic.fr/french/viewtopic.php?p=72718

More easier : you could use PureFORMs 'Background color / image' feature ...

Update (build 240)

Changes :
- fixed : PB compiler version check before compile/run was broken

gnozal wrote:

ar-s wrote:For exemple, i'm making a 400x400 window
I put an image to make a background for my application
This image is same size as window size.

So it is impossible to add a gadget (string gadget for exemple) over the image. We have to grow window size (400x600 for exemple), then create a gadget below image, then put the new gadget on image then resize window 400x400.

Could you make creating gadget over an image in next Build ?

Yes, you can't draw a gadget over another gadget, except for 'container' gadgets (panel / container / scrollarea) and Frame3D.
But, if you disable the image gadget ['Disable' button in gadget properties] you can draw a button in top of it ! You can enable the image later. The 'disabled' state has no effect on the generated code.
Note that the button won't work ... You will have to add the #WS_CLIPSIBLINGS style to the imagegadget and redefine the Z order like in http://www.purebasic.fr/french/viewtopic.php?p=72718

More easier : you could use PureFORMs 'Background color / image' feature ...

Ok thks gnozal

Hello gnozal,

I plan to port a growing project from the PB Visual Designer to PureFORM, but I encountered some problems during my first tests:
I used the function "translate from source" to port the gui code from VD to PureFORM.

The problems are:
- The StatusBar will not be took over. If I create a new one I have no option to change it's Enum constant.
- The Windowmenus were not be took over. If I create the missing menu manually I have no option to set the menu-Enum format nor I can edit them. The Enums are hardcoded to this format: #Menu_[WinEnum]_[Nb]_[Menutext], no matter what I choose in the project options. So I have to change all the constants in my program instead in the GUI.
- The images of the ImageButtonGadget have not been found

Is there a chance that you put in effort into this issues in the future?
(I can mail you the VD GUI-code for testing, if you want)

My biggest problem are the not editable menu-Enums, but maybe I am wrong and merely dont know all secret functions of PureFORM?

Markus

Update (build 241)

Changes :
- fixed : resized imagegadget width/height were not saved correctly after image loading (bug introduced with build 239)

kurzer wrote:Is there a chance that you put in effort into this issues in the future?

The 'Translate from source' feature is incomplete, it only imports windows and gadgets (missing : statusbar / menu / etc...) ...
I may improve it a bit, but it will never be perfect, as PureFORM handles some data it's own way (for example, some enumerations are not saved, they are generated in realtime).

kurzer wrote:My biggest problem are the not editable menu-Enums, but maybe I am wrong and merely dont know all secret functions of PureFORM?

The menu-Enums are not editable because they are not saved in the form, they are generated in realtime.

Thank you for the fast answer. So I will set to work and change the code before the projekt will grow up to fast.

But stop, there is one thing that could deters(?) me: I didn't test it yet, but what happens with the menu Enums if I insert a new menu item between two existing items? Or if I change the order of the items afterwards. I hope PureForm will not re-name all the Enums from scratch. If this is the case, then it's far away from practical orientation, because you have to adapt your code to the new generated structure of PureForm - You have to do this every time you change the menu structure - imagine what happens if you insert a new first menu item.

kurzer wrote:But stop, there is one thing that could deters(?) me: I didn't test it yet, but what happens with the menu Enums if I insert a new menu item between two existing items? Or if I change the order of the items afterwards. I hope PureForm will not re-name all the Enums from scratch.

Never thought of that ... !
That might be a problem, because the menu item index is part of the menu enum to ensure the constant is unique. But I can change that, and refuse two menu items with the same name in the same menu in the menu builder.

[EDIT]

Updated to build 242 : changed menu / toolbar enumeration (removed item index).
Note that the rest of the menu / toolbar item enum is based on the window enum and the item text. So it changes if any of the two changes.

gnozal wrote:Updated to build 242 : changed menu / toolbar enumeration (removed item index).
Note that the rest of the menu / toolbar item enum is based on the window enum and the item text. So it changes if any of the two changes.

Thank you again for the fast response. You wrote, you handle the Enums of the menu / toolbar in a different way applying to the Enums of gadgets or windows. But maybe you could change this in the future to the same logic. It would offer the most flexibility.
Is there a special reason why you choose another logic for menu and toolbar?

kurzer wrote:But maybe you could change this in the future to the same logic. It would offer the most flexibility.

Yes maybe, but optional.

kurzer wrote:Is there a special reason why you choose another logic for menu and toolbar?

Yes, because I like the menu enums to be generated automatically for the menu item text. I don't like typing enums myself, and the menu item text usually describes the menu item function. I missed this in other designers.

gnozal, you know that you are responsible for the two biggest threads in here right? hehehe

This one and the jaPBe 3.7.11 [IDE for PB 4.xx] thread.
Very popular threads those two.

GeoTrail wrote:gnozal, you know that you are responsible for the two biggest threads in here right? hehehe

This one and the jaPBe 3.7.11 [IDE for PB 4.xx] thread.
Very popular threads those two.

these tools are very usefull and Unavoidable

Update

Changes :
- fixed a bug in gadget group move if snap to grid was activated

gnozal wrote:

kurzer wrote:Is there a special reason why you choose another logic for menu and toolbar?

Yes, because I like the menu enums to be generated automatically for the menu item text. I don't like typing enums myself, and the menu item text usually describes the menu item function. I missed this in other designers.

Ehh? I can't follow your drift. The gadget enumerations are yet also generated Enums. More, you can even choose the way of the Enum generation (setup/configuration/code(1)/gadget enumeration)

What speaks against this logic (editable Enum-constants)?
You could place a seperate combobox in "setup/configuration/code(1)" to choose a different pattern for the manu and statusbar enumeration. If you then choose for example 'Class/Text' in this combobox, then you have the same resulting menu Enums like the 'hard wired' ones yet.

I try to understand what you induced to go this complete different way for menus / statusbars. But I really can't see...
(Nevertheless a great program, please don't take my teasing personally)

With respect, Markus

PS: I hope I can pay it back someday, but there are so many suggestions for PureFORM in my head...
If you work on the menu-part of PureFORM, you can possibly build in a automation for menu shortcuts and the "&" sign in button-gadgets? At the moment one have to create the code for such shortcut-events manually in the OpenWindow-procedure and the event loop.

Really cool work you've done with PureFORM.

Just on suggestion: What about support for popup menus?