Restored from previous forum. Originally posted by Franco.
How about doing both:
PG_CreateGadget(#Button,Window1,320,10,100,25,"Button","ToolTip", MyProcedure(W,X,Y,Z) )
PG_CreateGadget(#Button,Window1,320,10,100,25,"Button","ToolTip", ?MyLabel )
Well The correct syntax would be:
PG_CreateGadget(#Button,Window1,320,10,100,25,"Button","ToolTip", @MyProcedure(W,X,Y,Z) )
PG_CreateGadget(#Button,Window1,320,10,100,25,"Button","ToolTip", ?MyLabel )
BUT SORRY, when releasing PureGUI I have to think about further development (PureGUIDE) and I prefer Subroutines.
So if you call Procedures instead of Subroutines and PUREGUIDE will be released (one fine day...) you have to change your exsting code to use PUREGUIDE.
And like I said the Subroutine is only used to JUMP to the function related to the GUI event. The more modular you code at the beginning the less rework you will have in the future.
-------------------------------------------------------------------------------------
THIS WILL BE THE MAIN WAY TO CODE 'MODULAR' IN PUREGUIDE:
At the end of every PureGUI main code will be a IncludeFile command to store all the needed Subroutines in this file.
Every GUI event jumps to such a subroutine and in this subroutine is a 'XIncludeFile' command that jumps to another Include file, and finally in THIS file you can code WHATEVER YOU WANT.
What you code in this File - Procedures or whatever - is up to you.
At THIS POINT you are able to code YOUR WAY!
Dependencies from one Procedure to another can be solved with the new Declare command of PureBasic.
-------------------------------------------------------------------------------------
AND IN THE FUTURE:
In PureGUIDE you can press the right mouse button over your Gadget and the file called with 'XIncludeFile' will show up and you are able to write your code...
This is my intention - and with this style nobody will need a foldable editor.
The *CreateGadget*(1 / 3) method keeps the number of *new* commands introduced into PB to 1 whereas the PG_ButtonGadget(2) method requires at least a dozen new commands - a page of documentation for each command. I think *CreateGadget* would more readily encompass new GadgetTypes.
Yes using CREATE... the overhead of an application would be smaller.
And the documentation issue is a good point to think about.
The Syntax would be:
PG_Create("ButtonGadget",WindowNB,PosX,PosY,SizeX,SizeY,Text$,ToolTip$,LMB_Command,RMB_Command)
PG_Create("CheckBoxGadget",WindowNB,PosX,PosY,SizeX,SizeY,Text$,ToolTip$,LMB_Command,RMB_Command)
PG_Create("TextGadget",WindowNB,PosX,PosY,SizeX,SizeY,Text$,"",0,0)
PG_Create("StringGadget",WindowNB,PosX,PosY,SizeX,SizeY,Content$,ToolTip$,LMB_Command,0)
PG_Create("ButtonImageGadget",WindowNB,PosX,PosY,SizeX,SizeY,Image$,ToolTip$,LMB_Command,RMB_Command)
PG_Create("ImageGadget",WindowNB,PosX,PosY,SizeX,SizeY,Image$,"",0,0)
PG_Create("ProgressBarGadget",WindowNB,PosX,PosY,SizeX,SizeY,"","",Min,Max)
You see that there must be the same amount of parameters and the data type must be the same.
That's because PureBasic doesn't allow changing the number of parameters for the same procedure [for now]. (remember: PureGUI is coded in PureBasic...)
The Procedure approach(3) would be very readable and therefore easily maintained
Sorry, please read THE MAIN WAY above...
After PureGUI is released you are able to call procedures - BUT you have to change your code if you want to use PUREGUIDE one fine day.
I just think this syntax:
PG_CreateGadget(#Button,Window1,320,10,100,25,"Button","ToolTip",MyProcedure(PG_ButtonAction,PG_GadgetValue$,PG_GadgetIndex))
would allow you to incorporate it in syntactically one day (perhaps) more easily.
NOPE because you can only declare '1 action / 1 value / 1 index' at a time.
If I would call your syntax I must call PG_CreateGadget twice to set first LMB and than RMB. ( and I would create 2 Buttons...)
I want be able to set 2 Actions at 1 time for LMB/RMB
Forgot to mention that there will be 2 commands to fill the syntax:
PG_NoFunctionNeeded() and PG_NoFunctionAssigned()
you code:
PG_Create("ButtonGadget",WindowNB,PosX,PosY,SizeX,SizeY,Text$,ToolTip$,@PG_NoFunctionAssigned(),@PG_NoFunctionNeeded())
In this way you can test the GUI code before you code the functions behind the events.
PG_NoFunctionNeeded() will do nothing (used if you don't need a function for RMB [in the example]) The action behind PG_NoFunctionAssigned is that you will get a little window with a reminder like "You have to code a function for this Gadget".
Have a nice day...
Franco
Sometimes you have to go a lonely way to accomplish genius things.
Edited by - franco on 01 May 2002 19:36:33
I still look forward to seeing the results real soon...