Hello,
Does anyone know how PB assigns class names to apps opened through it.
I see that some are called WindowClass_0, others WindowClass_2, perhaps there are other increments as well?
Thanks for enlightening my foggy brain.
PB and WindowClass_X
PB and WindowClass_X
If my English syntax and lexicon are incorrect, please bear with Google translate and DeepL. They rarely agree with each other!
Except on this sentence...
Except on this sentence...
Re: PB and WindowClass_X
Hi boodhi,
here is my explanation (based on observations)
Since all controls under windows are (only) windows, different properties and behaviors are registered by the classes. (see RegisterClassEx function and WNDCLASSEX structure)
You can only assign a class to windows and controls when creating them. (see CreateWindowEx function)
For the main window PB uses a (free selectable) name "WindowClass_0", like
So the main window name is not tied to specifications from windows, but freely selectable.
I have not yet found an explanation for the different numbers.
If I want to search for my own program via EnumChild(), I always check the "Classname" beforehand so that I don't get any surprises.
I remember that we had a (short) discussion on PB should make the Classname available to us by adding a parameter but Fred (unfortunately) refused.
There are samples of doing it by yourself with CreateWindowEx_.
BTW: The PB-IDE on my system has a Classname == "WindowClass_2" and the "Debug Output - " window uses WindowClass_2242169232944.
Hope this helps, or motivated others to supplement.
here is my explanation (based on observations)
Since all controls under windows are (only) windows, different properties and behaviors are registered by the classes. (see RegisterClassEx function and WNDCLASSEX structure)
You can only assign a class to windows and controls when creating them. (see CreateWindowEx function)
For the main window PB uses a (free selectable) name "WindowClass_0", like
Code: Select all
Protected hWnd = CreateWindowEx_(0,"WindowClass_0","The title of my window",#WS_OVERLAPPEDWINDOW,x,y,430,430,#Null, #Null, wc\hInstance, #Null)
So the main window name is not tied to specifications from windows, but freely selectable.
I have not yet found an explanation for the different numbers.
If I want to search for my own program via EnumChild(), I always check the "Classname" beforehand so that I don't get any surprises.
I remember that we had a (short) discussion on PB should make the Classname available to us by adding a parameter but Fred (unfortunately) refused.
There are samples of doing it by yourself with CreateWindowEx_.
BTW: The PB-IDE on my system has a Classname == "WindowClass_2" and the "Debug Output - " window uses WindowClass_2242169232944.
Hope this helps, or motivated others to supplement.
Just because it worked doesn't mean it works.
PureBasic 6.04 (x86) and <latest stable version and current alpha/beta> (x64) on Windows 11 Home. Now started with Linux (VM: Ubuntu 22.04).
PureBasic 6.04 (x86) and <latest stable version and current alpha/beta> (x64) on Windows 11 Home. Now started with Linux (VM: Ubuntu 22.04).
Re: PB and WindowClass_X
Thanks for your explanation.Axolotl wrote: here is my explanation (based on observations)
For my part, after investigation, my conclusion is that numeral suffix corresponds to the constant or variable value or ID returned by #PB_Any at the moment of window creation.
Maybe, certainly, some people knew that, but for me it's a real discovery.
My application windows have always short numbers because I use constants starting from 0 and the suffix is always the constant value.
Except for the tools in the Tools menu and some other windows, PB uses short numbers too, some examples:
WindowClass_1: Debugger
WindowClass_2: IDE
WindowClass_4: Prefs
WindowClass_10: Compiler options
WindowClass_26: History session
If my English syntax and lexicon are incorrect, please bear with Google translate and DeepL. They rarely agree with each other!
Except on this sentence...
Except on this sentence...
Re: PB and WindowClass_X
Windows only.
Sometimes it is better to have a separate ClassName for the window.
For example, to find a window via the ClassName and not via the window title.
Link: OpenClassWindow
Sometimes it is better to have a separate ClassName for the window.
For example, to find a window via the ClassName and not via the window title.
Link: OpenClassWindow
My Projects ThreadToGUI / OOP-BaseClass / EventDesigner V3
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
Re: PB and WindowClass_X
Hello,mk-soft wrote: Link: OpenClassWindow
Thanks for your link. I'll take a deeper look at it
But, as I'm not a great specialist in Windows APIs, and to make it easier to manage the positioning and resizing of windows/gadgets, I've taken to using the Dialog library.
The result, as you know, is that the class name is automatically assigned by PB, like with classic OpenWindow().
This raises a new (stupid?) question: Can the name of this class be change after the window creation?
PS: It's not a need, just by curiosity.
If my English syntax and lexicon are incorrect, please bear with Google translate and DeepL. They rarely agree with each other!
Except on this sentence...
Except on this sentence...
Re: PB and WindowClass_X
No, that is not possible
My Projects ThreadToGUI / OOP-BaseClass / EventDesigner V3
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
PB v3.30 / v5.75 - OS Mac Mini OSX 10.xx - VM Window Pro / Linux Ubuntu
Downloads on my Webspace / OneDrive
Re: PB and WindowClass_X
I suspected as much.
Thanks.
Thanks.
If my English syntax and lexicon are incorrect, please bear with Google translate and DeepL. They rarely agree with each other!
Except on this sentence...
Except on this sentence...


