So in a function which accepts wstring pointers, should I deallocate the memory used then, or does leaving the function do that automatically?MrSwiss wrote: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
Object-Oriented GUI Library
-
- Posts: 355
- Joined: May 29, 2015 20:37
Re: Object-Oriented GUI Library
Re: Object-Oriented GUI Library
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):
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.
-
- Posts: 355
- Joined: May 29, 2015 20:37
Re: Object-Oriented GUI Library
Version 1.1 has now been officially released, with support for Unicode!kcvinu wrote:Hi,
Does this library supports 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.
Re: Object-Oriented GUI Library
Hi datwill310,
Thanks a lot. This is unbelievably fast. I am downloading and going to test it.
Thanks a lot. This is unbelievably fast. I am downloading and going to test it.
Re: Object-Oriented GUI Library
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 ?
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 ?
Re: Object-Oriented GUI Library
Since Destructor(s) are ONE to a TYPE, and there are multiple TYPE(s) in the Lib,kcvinu wrote: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
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)
-
- Posts: 355
- Joined: May 29, 2015 20:37
Re: Object-Oriented GUI Library
Firstly, I'm glad to hear that it's working ;D! And I thank you for your participation in the creation of OGL!kcvinu wrote: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 ?
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.
Again, thanks for your time!
-
- Posts: 355
- Joined: May 29, 2015 20:37
Re: Object-Oriented GUI Library
Hi,PaulSquires wrote:And it doesn't look like the library is High-DPI aware either?
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...
Last edited by datwill310 on Dec 29, 2016 10:43, edited 1 time in total.
Re: Object-Oriented GUI Library
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.
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.
-
- Posts: 355
- Joined: May 29, 2015 20:37
Re: Object-Oriented GUI Library
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).marcov wrote: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.
Is this what you mean, or am I getting the wrong end of the stick? Thanks again for your input.
-
- Posts: 355
- Joined: May 29, 2015 20:37
Re: Object-Oriented GUI Library
Notice
Version 2.0 is currently complete. All I've got to do now is:
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.
Version 2.0 is currently complete. All I've got to do now is:
- Rewrite the documentation.
- Rewrite the examples.
- Upload to GitHub.
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.kcvinu wrote: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 of the OGL still supports Unicode.kcvinu wrote:Hi,
Does this library supports UNICODE ?.
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).PaulSquires wrote:And it doesn't look like the library is High-DPI aware either?
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.
Re: Object-Oriented GUI Library
I meant to say there are two ways of registering. One in a hierarchy for windows messages, one for owner ship (and thus freeing).datwill310 wrote: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).marcov wrote: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.
Is this what you mean, or am I getting the wrong end of the stick? Thanks again for your input.
If the child knows who owns it, it can also deregister itself if needed.
Re: Object-Oriented GUI Library
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.
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.
-
- Posts: 355
- Joined: May 29, 2015 20:37
Re: Object-Oriented GUI Library
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.kcvinu wrote: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.
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.
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?marcov wrote:I meant to say there are two ways of registering. One in a hierarchy for windows messages, one for owner ship (and thus freeing).datwill310 wrote: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).marcov wrote: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.
Is this what you mean, or am I getting the wrong end of the stick? Thanks again for your input.
If the child knows who owns it, it can also deregister itself if needed.
Thanks for you time.
-
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Re: Object-Oriented GUI Library
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.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...
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
' ========================================================================================