Object-Oriented GUI Library

[datwill310]

Yes, but the Ptr issue is not that hard to solve, since,
usually the Pointers use fixed length (String/WString):

Code: Select all

Dim As String Ptr pStr = CAllocate(260) ' or
Dim As WString Ptr pWStr = CAllocate(260 * 2)

... ' use them
*pWStr = "any text you like!" ' assign
Print *pWStr ' output
... ' use finished

' deallocate to free used MEM
Delete pStr : pStr = 0 ' or
Delete pWStr : pWStr = 0

So in a function which accepts wstring pointers, should I deallocate the memory used then, or does leaving the function do that automatically?

[MrSwiss]

Usually the Ptr is CAllocated(size) before you "hand it over" to a Sub/
Function. Therefore, you would NOT want the Procedure to "destroy it".

Like mentioned in previous post "destroy/deallocate" after use ...

You can use the same Ptr multiple times (just destroy the held value):

Code: Select all

Sub set_xy(ByRef z As Const WString Ptr) ' z can't be changed!
    Some_API_set(z)
End Sub

Sub get_xy(ByRef z As WString Ptr) ' z will be changed (new assignment)
    Some_API_get(z)
End Sub

'' Main

*z = "Program Title"
set_xy(z) ' set programs Title (WString)
*z = "" ' wstring is now 'empty' before using a getter
get_xy(z) ' z is getting a new WString here
Print *z ' output the freshly gotten WString

etc.

[datwill310]

Hi,
Does this library supports UNICODE ?.

Version 1.1 has now been officially released, with support for Unicode!

I've tested the new library with my examples, and they all work the same, except for Example 4, due to the dir command not being able to read Unicode filenames (is this true or am I being stupid?).

Two other additions include allowing Checkboxes to become non-automatic and the addition of the enabled and visible properties to the BASE_CLASS.

Enjoy! If there any problems or bugs, please let me know ASAP.

[kcvinu]

Hi datwill310,
Thanks a lot. This is unbelievably fast. I am downloading and going to test it.

[kcvinu]

Wow... Thanks. Its working.
One doubt. You are using so many destructors at the end of the program. Can you make it single one. Like "MyGui.Destructor()". For example, if the variable name of the window is "MyGui" and it contains lot of controls but with this function call, all of that controls should need to destruct. Is it possible ?

[MrSwiss]

You are using so many destructors at the end of the program. <==> as many, as there are Type(s)
Can you make it single one? <==> simple answer: NO

Since Destructor(s) are ONE to a TYPE, and there are multiple TYPE(s) in the Lib,
each of them is called (however, this should be done automatically in OO).

The only manually called "Memory release" methods are for temporary variables,
which have no TYPE associations. (Declared "outside" of a TYPE context.)

Since you clearly don't understand the OO-concept: READ and UNDERSTAND the
DOCUMENTATION of OGL! (The provided .chm file! Sections: titled OO)

[datwill310]

Wow... Thanks. Its working.
One doubt. You are using so many destructors at the end of the program. Can you make it single one. Like "MyGui.Destructor()". For example, if the variable name of the window is "MyGui" and it contains lot of controls but with this function call, all of that controls should need to destruct. Is it possible ?

Firstly, I'm glad to hear that it's working ;D! And I thank you for your participation in the creation of OGL!

In one sense, your suggestion is already implemented! When a parent window is destroyed, all its child windows are also destroyed before it is, in turn, destroyed.

But in another, not manually destructing the child window objects could lead to memory leaks. A child window may have already been destroyed, but the memory used to store that information in Free BASIC/the OGL has NOT been destroyed. This is why we do so in the OGL. Technically, the DestroyWindow function will not work with child controls if the child control associated with it is already destroyed due to a previous call to the parent window's destructor! But regardless of this, we still need to provide the destructor to clear up the memory associated with the object.

I can only think of one way of fulfilling your request off the top of my head: and that is to provide methods to register child control objects to be destroyed with their parent object when it is destroyed, but the solution may lead to:

• Potentially dangerous/dodgy code.
• Provides just more code for you to type.
• And even if we could find a way to keep code as short as possible, it would probably lead to a loss of power at the programmer's end, and it could be a step back in terms of simplicity and speed.

You know: if there was a way, I would code it! I fully agree that this feature should be implemented! But the implementations I can think of just wont work.

Again, thanks for your time!

[datwill310]

And it doesn't look like the library is High-DPI aware either?

Hi,

I've taken a look at one of the tutorials on the MSDN. Seems simple enough... I think some of the work as to be at the programmer's end, but maybe I could create standard adjustment methods (or am I misunderstanding this?)?

Thanks and will definitely consider implementation.

EDIT: Also have come across process-level and thread-level functions? Should I only set DPI awareness for the current process, or the current thread? Coming to think of it, what exactly are the differences between them? You can have multiple processes (eg a multi-instance application), but only one thread (all processes are part of the one thread), or is it the other way round (suggested here)?
NOTE: I use the GetModuleHandle(0) with the CreateWindowEx() function in this library. That means all the windows are created within the current process, right? So that means I should use the process-level functions?

EDIT: Also having trouble trying to find which FB header file declares the functions for DPI awareness? I've made searches within the inc\win folder, and I've even downloaded José's library to see if I could find the header file used, but I found nothing... Process-level functions are defined within the shellscalingapi.h header file for C[++], and I've even checked whether there is a header file called "shcore.bi" - still nothing...

[marcov]

Don't make ownership implied if a child is registered with the owner

E.g. in Delphi a parent has two arrays with ptrs to childs:
- 1 called "parent" for Wincontrol message flow
- 1 called "owner" to register the subcontrol to free on end.

The child has these references (owner and parent) too.

[datwill310]

Don't make ownership implied if a child is registered with the owner

E.g. in Delphi a parent has two arrays with ptrs to childs:
- 1 called "parent" for Wincontrol message flow
- 1 called "owner" to register the subcontrol to free on end.

The child has these references (owner and parent) too.

If what you are saying is to actually register child controls to an APPWINDOW object, then yes, that is definitely an option that should be incorporated (this could also solve kcvinu's query about not explicitly calling destructors within a programmer's piece of code).
Is this what you mean, or am I getting the wrong end of the stick? Thanks again for your input.

[datwill310]

Notice

Version 2.0 is currently complete. All I've got to do now is:

• Rewrite the documentation.
• Rewrite the examples.
• Upload to GitHub.

Sounds easy, but it isn't...

Wow... Thanks. Its working.
One doubt. You are using so many destructors at the end of the program. Can you make it single one. Like "MyGui.Destructor()". For example, if the variable name of the window is "MyGui" and it contains lot of controls but with this function call, all of that controls should need to destruct. Is it possible ?

This Version will hopefully answer this question. Child controls no longer have their own classes, but are a list of methods and fields within the parent class. This allows you to simply call "MyGui.Destructor()" without having to destruct every child control (this is all done for you!). Of course, you can still manually destroy child controls as you see fit.

Hi,
Does this library supports UNICODE ?.

This version of the OGL still supports Unicode.

And it doesn't look like the library is High-DPI aware either?

The OGL is not High-DPI aware yet. Honestly, I am a bit confused by it (would appreciate it if somebody could help me with the questions I asked earlier).

I also plan to re-implement some of the beta features such as menus and custom fonts. These are not yet included, however.

The OGL has really changed from it's first version. I promise this is the last time that I will change the OGL to this extent (the syntax is very different, as is the way it handles things). Of course, if this maybe isn't the best way to do things, then I will have to go back to the old, first version. Hopefully this isn't going to have a knock-on on developing programs as not many people use it (? <:D idk!).

Thanks for your support.

[marcov]

Don't make ownership implied if a child is registered with the owner

E.g. in Delphi a parent has two arrays with ptrs to childs:
- 1 called "parent" for Wincontrol message flow
- 1 called "owner" to register the subcontrol to free on end.

The child has these references (owner and parent) too.

If what you are saying is to actually register child controls to an APPWINDOW object, then yes, that is definitely an option that should be incorporated (this could also solve kcvinu's query about not explicitly calling destructors within a programmer's piece of code).
Is this what you mean, or am I getting the wrong end of the stick? Thanks again for your input.

I meant to say there are two ways of registering. One in a hierarchy for windows messages, one for owner ship (and thus freeing).

If the child knows who owns it, it can also deregister itself if needed.

[kcvinu]

Hi datwill310,
Thanks for the updates. I am happy that you include my suggestions in the latest version. I have started a hobby project in VB.Net for OGL. A visual designer for OGL. I am sorry that it is progressing on a slow pace because, i have a few hours to work for it. And besides that, i need to learn a lot for make it true. Especially graphics. Now, i have completed control creation and selection. This is the TO DO List.
1. Make the pointer tool work.
2. Implement dragging facility for selected controls.
3. Make the property window and Events window. And project tree.
4. At last, code generation as per created form and controls.

[datwill310]

Hi datwill310,
Thanks for the updates. I am happy that you include my suggestions in the latest version. I have started a hobby project in VB.Net for OGL. A visual designer for OGL. I am sorry that it is progressing on a slow pace because, i have a few hours to work for it. And besides that, i need to learn a lot for make it true. Especially graphics. Now, i have completed control creation and selection. This is the TO DO List.
1. Make the pointer tool work.
2. Implement dragging facility for selected controls.
3. Make the property window and Events window. And project tree.
4. At last, code generation as per created form and controls.

Sounds cool! I'm sorry that I'm changing the OGL so much :-( - it's not a major change, I think the program can adapt depending on how you've programmed it.
Lol, I had a nasty shock when I spotted a bug in the indexing within the control creation methods XO. Hopefully I've fixed it XD.

Don't make ownership implied if a child is registered with the owner

E.g. in Delphi a parent has two arrays with ptrs to childs:
- 1 called "parent" for Wincontrol message flow
- 1 called "owner" to register the subcontrol to free on end.

The child has these references (owner and parent) too.

If what you are saying is to actually register child controls to an APPWINDOW object, then yes, that is definitely an option that should be incorporated (this could also solve kcvinu's query about not explicitly calling destructors within a programmer's piece of code).
Is this what you mean, or am I getting the wrong end of the stick? Thanks again for your input.

I meant to say there are two ways of registering. One in a hierarchy for windows messages, one for owner ship (and thus freeing).

If the child knows who owns it, it can also deregister itself if needed.

I think I've solved this issue with the new version? Controls all belong to a parent class. There are protected arrays which hold control handles, which are used for both messages and are generated when created with CreateWindowEx(), and can be destroyed with DestroyWindow() (all within the parent class). Does this solve the issue?

Thanks for you time.

[Josep Roca]

EDIT: Also having trouble trying to find which FB header file declares the functions for DPI awareness? I've made searches within the inc\win folder, and I've even downloaded José's library to see if I could find the header file used, but I found nothing... Process-level functions are defined within the shellscalingapi.h header file for C[++], and I've even checked whether there is a header file called "shcore.bi" - still nothing...

They belong to the WinUser header file, but they have not been included in the FB .bi files. Therefore, you have to call them dynamically, e.g.

Code: Select all

' ========================================================================================
' Sets the current process as dots per inch (dpi) aware.
' Note: SetProcessDPIAware is subject to a possible race condition if a DLL caches dpi
' settings during initialization. For this reason, it is recommended that dpi-aware be set
' through the application (.exe) manifest rather than by calling SetProcessDPIAware.
' Return value: TRUE on success; FALSE on failure.
' ========================================================================================
PRIVATE FUNCTION AfxSetProcessDPIAware () AS BOOLEAN
   DIM AS ANY PTR pLib = DyLibLoad("user32.dll")
   IF pLib = 0 THEN EXIT FUNCTION
   DIM pProc AS FUNCTION () AS LONG
   pProc = DyLibSymbol(pLib, "SetProcessDPIAware")
   IF pProc = 0 THEN EXIT FUNCTION
   FUNCTION = pProc()
   DyLibFree(pLib)
END FUNCTION
' ========================================================================================