Page 50 of 52

Re: IceDesign GUI designer

Posted: Wed Nov 12, 2025 6:37 pm
by Clanzer
ChrisR wrote: Mon Jun 17, 2024 10:43 pm
blueb wrote: Mon Jun 17, 2024 4:07 pm I found that everything works very well for resizing (Forms, Buttons, etc)
except the font sizes on the buttons, etc. which remain the same.
I don't know if it's suitable for everyone, but maybe there's something I could add.
I'm saving the idea for after the summer vacation which is closer for me.

If you use the same font for all Gadgets, you can probably do it with something like this
Purchased IceDesign and well worth the money.

The auto gadget re-size works great in IceDesign and adding the font re-size routine would be great.

Cheers

Sean

Re: IceDesign GUI designer

Posted: Fri Nov 14, 2025 4:56 pm
by ChrisR
Hi Sean,
About the font re-size routine, I still have the same doubts about its usefulness and common practice.
I asked ChatGPT what is generally done in practice to resize fonts relative to window size.
Here is his answer (translated with DeepL), more complete than I could provide:
In desktop UI development (including in PureBasic), resizing the window does not usually involve automatically resizing fonts.
And it is not common practice to resize text proportionally to the window.

Here are the usual practices and reasons:

⭐ Common practice in most applications

Fonts remain fixed even if the window is enlarged.
Controls can be enlarged (gadgets, text boxes, lists, etc.).

This allows you to:
- display more text content (string gadgets, editor gadgets, etc.),
- avoid a “cartoon” effect where everything is unnecessarily enlarged,
- maintain visual consistency (the typography does not change with each resize).

This is what the following do:
- Windows Explorer
- Browsers
- Most office applications
- File managers, text editors, etc.

⭐ When do we resize the font?

Rarely, but it can be done in two cases:

1. Highly graphical or presentation-oriented interfaces

E.g.: drawing software, control panels, touch screens, dashboards.
Objective: to maintain consistent readability on a large screen.

2. Accessibility feature / User zoom

Some software offers:
- interface zoom (an option in the preferences),
- or a customizable font.

But this is never automatically linked to simply resizing the window.
...
I don't have much time right now, but maybe it could be considered as an option if there is a real need !

Re: IceDesign GUI designer

Posted: Fri Nov 14, 2025 7:45 pm
by Clanzer
ChrisR wrote: Fri Nov 14, 2025 4:56 pm Hi Sean,
About the font re-size routine, I still have the same doubts about its usefulness and common practice.
I don't have much time right now, but maybe it could be considered as an option if there is a real need !
Hi Chris

Thanks for the info, but I do not really understand why it is not useful.

The code example you pasted in a earlier post worked great and re-sized the fonts.
If the fonts are not re-sized I get the following where in the normal start size the screen looks like this
Image

Then after re-sizing you can see in picture below that the fonts cannot be read
Image

With the Titles like Enter Bobbin Width I created images that re-size okay to get around the fonts not re-sizing.

Or am I missing something here that I am not setting somewhere?

Thanks

Sean

Re: IceDesign GUI designer

Posted: Fri Nov 14, 2025 11:14 pm
by ChrisR
Thanks for the pictures, Sean
I understand better the usefulness of having proportional fonts here, less for strings or editor gadgets allowing more text to be displayed.
It could be an additional option in the settings associated with "Proportional size for all gadget"
I can't promise anything for timing, as I'm quite busy at the moment, but I'll look into it.

Another option to consider, to avoid being below the minimum required size for gadgets would be to design for the minimum window size and specify the minimum window bounds in its properties.

Re: IceDesign GUI designer

Posted: Fri Dec 05, 2025 3:05 pm
by ChrisR
IceDesign has been updated in version 2.3.8
  • Add the option: Font size scaled
    It is a sub-option of "Proportional Size for All Gadgets"

    Note: By default, most applications and classic interfaces do not use this font scaling but only scaling based on DPI

Re: IceDesign GUI designer

Posted: Sat Dec 06, 2025 1:27 pm
by Clanzer
Brilliant !

Works like a charm, thank you so much Chris :D
ChrisR wrote: Fri Dec 05, 2025 3:05 pm IceDesign has been updated in version 2.3.8

Re: IceDesign GUI designer

Posted: Sat Dec 06, 2025 1:36 pm
by BarryG
Just downloaded the demo for another look. Wow, this is fantastic! I may want to use this for future projects.

One thing is stopping me buying at the moment: I put a ButtonGadget on the form, but I can't see any way to tell it a procedure to call when clicked, or when right-clicked, etc? Because when I create the code for it and run it, clicking the button shows a message box with some text. Is that meant to be in the editor somewhere?

I'd love the properties box to have a section called "Procedures" and entry boxes for left, middle, and right clicks; and keypress, where we can name our own procedures in each box for mouse clicks and keypresses to be called for that gadget. I could then have my own standalone "Procedures.pbi" file that wouldn't be affected by editing the gadgets on the form. This would be the nail in the coffin that makes me buy. :)

Image

Re: IceDesign GUI designer

Posted: Sat Dec 06, 2025 7:47 pm
by ChrisR
Thanks Clanzer, glad it responded to your request :)

Hi BarryG,thank you for trying it out and glad that you like it.
For now, there is no section titled “Procedures” with input fields for left, middle, and right clicks or key presses in the properties but it's a good idea
However, there is the “Bind Event” property but the procedure name cannot be changed,
it is automatically generated based on the Gadget name (#Button_Yes --> Procedure Event_Button_Yes()).
It is also possible to do the same for All Gadgets, in the settings with the option "Bind All Gadgets Events" and with the optional sub-option “Bind Events in an IncludeFile”

Image

Re: IceDesign GUI designer

Posted: Sun Dec 07, 2025 2:51 am
by BarryG
Oh, I see. I tried ticking "Bind Event" and I see what you mean, but "Bind Events in an IncludeFile" still gets overwritten when I click "Create Code" (F7), so I can't use it. I need a way for my gadget event codes that I add to always be kept safe, no matter what I do for the GUI gadgets in the form editor.

If I could just name a procedure for a left/middle/right click, and for a keypress, then I can just use my own IncludeFile for my gadgets (nothing to do with IceDesign) and therefore all is safe and not overwritten with F7. :)

Re: IceDesign GUI designer

Posted: Sun Dec 07, 2025 10:52 am
by Joe
Hi Chris,
regarding the "Bind Event" in above Picture:
"Create Code" still puts the Procedures into the form code, even if "Bind Events in an IncludeFile" is checked.

"Create Code" also puts a
;- Main Program
If Open_frmMain()

Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf
into the form code, even if "Add Compiler isMainFile" is unchecked.

So, after creating the form code, both sections has to be deleted by hand ...

And while I'm just writing ..-Can you pls but a "#SS_Notify" to to TextGadget constants?

Cheers, Joe

Re: IceDesign GUI designer

Posted: Sun Dec 07, 2025 12:56 pm
by ChrisR
@BarryG
I also understand your request, but I don't really see how I could do it!

The code is generated to be always functional right out of the box, with also the preview and I think that's an important point for a designer.
I have no problem with the automatically generated procedure names, they are always in sync between BindGadgetEvent() and the procedure names written.

But I don't know how I could get a 100% functional code with specific procedure names BindGadgetEvent(), but without these procedures in the generated code, defined by the user elsewhere in an included file.
Also, I don't see an easy solution to avoid overwriting and preserve the changes made by a user in the Bind Event procedures, and create them if they do not already exist.

Re: IceDesign GUI designer

Posted: Sun Dec 07, 2025 1:39 pm
by ChrisR
@Joe
I'll look into “Bind Events in an IncludeFile”, currently it is used only as a sub-option of “Bind All Gadgets Event” in the settings.
But, indeed, it should also work with the Bind Event property if defined for 1 or more Gadgets.

There is a misunderstanding, I believe about “Add Compiler isMainFile”
This option only adds "CompilerIf #PB_Compiler_IsMainFile" to the source code before the Open window and the event loop.

Code: Select all

;- Main Program
If Open_frmMain()

Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf
Is always written but inside "CompilerIf #PB_Compiler_IsMainFile and CompilerEndIf" if the option is enabled
It means that Open_frmMain() and the event loop are included in the compilation and operational if you execute this source code directly, to test this window individually for example.
But it is not included in the compilation if this code is included and called from another main source code (MainFile).

I don't know in which case you use #SS_Notify with a TextGadget, but no problem, I can add it.

Re: IceDesign GUI designer

Posted: Sun Dec 07, 2025 3:25 pm
by Joe
Might be a mistunderstandig!?

I want to create the form with IceDesigner and include the generated code in the main program.

How can I get rid of these Open_frmMain()

It will be called from the Main program.

THX Joe

Re: IceDesign GUI designer

Posted: Sun Dec 07, 2025 5:52 pm
by ChrisR
Joe wrote: Sun Dec 07, 2025 3:25 pm I want to create the form with IceDesigner and include the generated code in the main program.
You mean, include with: XIncludeFile "YourForm.pb" in the main program not by copy/paste
If yes and it's the right way to do it, then enable the option “Add Compiler isMainFile” for your form
When you compile your main program, your form included will not be the Main File and therefore all the code between CompilerIf #PB_Compiler_IsMainFile and CompilerEndIf will not be included in the compilation.

Example:
YourForm.pb

Code: Select all

Procedure Event_Button()
EndProcedure

Procedure Open_Window(X = 0, Y = 0, Width = 240, Height = 90)
  If OpenWindow(0, X, Y, Width, Height, "Title", #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_ScreenCentered)
    ButtonGadget(0, 20, 20, 200, 50, "Button")
    BindGadgetEvent(0, @Event_Button())
    ProcedureReturn #True
  EndIf
EndProcedure

CompilerIf #PB_Compiler_IsMainFile
; Not included if compiling from a main file
If Open_Window()
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf
CompilerEndIf

MainFile.pb

Code: Select all

XIncludeFile "YourForm.pb"
; Main code:
If Open_Window()
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

When compiling MainFile.pb, the code seen by the compiler will be:

Code: Select all

Procedure Event_Button()
EndProcedure

Procedure Open_Window(X = 0, Y = 0, Width = 240, Height = 90)
  If OpenWindow(0, X, Y, Width, Height, "Title", #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_ScreenCentered)
    ButtonGadget(0, 20, 20, 200, 50, "Button")
    BindGadgetEvent(0, @Event_Button())
    ProcedureReturn #True
  EndIf
EndProcedure

; Main code:
If Open_Window()
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

So you can test YourForm.pb on its own or test MainFile.pb, without the Open_Window() and event loop from YourForm

Re: IceDesign GUI designer

Posted: Sun Dec 07, 2025 6:44 pm
by Joe
Ahh, I've to include to get rid off :D
My fault :(

THX Chris