Author |
Topic: GUILIB (Read 623 times) |
|
Matt
Developer
member is offline
Gender: 
Posts: 210
|
 |
Re: GUILIB
« Reply #11 on: Dec 8th, 2013, 1:03pm » |
|
Hi Richard,
I've been spending the past few days briefly studying the Liberty BASIC help file, the help files on BB4W and Windows for windows and dialog boxes, and the new GUILIB spec. Suffice it to say that I'm finding it hard going. From my perspective, some of it feels a little like rocket science. This may indicate that I'm not the right person to try to write a GUI library (current style DLG library, perhaps, but...)
Having said that, here are my thoughts and some questions.
Following are simple dialog box programs in the main program for BB4W and for Liberty BASIC using the current formats.
Code: REM Example dialog program for BB4W
INSTALL @lib$ + "WINLIB2"
ON ERROR IF !dlg% <> 0 THEN PROC_closedialog(dlg%) : END
ON CLOSE IF !dlg% <> 0 THEN PROC_closedialog(dlg%) : QUIT
ON SYS SysClick% = @wparam% : RETURN
dlg% = FN_newdialog("Example dialog", 100, 100, 100, 50, 8, 200)
PROC_pushbutton(dlg%, "Close", 2, 30, 30, 45, 15, 0)
PROC_static(dlg%, "Example dialog", 100, 5, 5, 70, 10, 0)
PROC_showdialog(dlg%)
SysClick% = 0
REPEAT
REPEAT
Click% = 0
WAIT 1
SWAP SysClick%, Click%
UNTIL Click% <> 0
REM Click controls
UNTIL Click% = 2 OR !dlg% = 0
IF !dlg% <> 0 THEN PROC_closedialog(dlg%)
QUIT
Code:REM Example dialog program for Liberty BASIC
STATICTEXT #dialog.static, "Example dialog", 8, 8, 120, 15
BUTTON #dialog.button, "Close", [close], UL, 40, 45, 70, 25
UpperLeftX = 30
UpperLeftY = 50
WindowWidth = 160
WindowHeight = 110
OPEN "Example dialog" FOR dialog_modal AS #dialog
PRINT #dialog, "trapclose [close]"
WAIT
[close]
CLOSE #dialog
END
Following is an example of what I think you might be after as a main program part.
Code: REM Example dialog program that might use new GUILIB
INSTALL @lib$ + "GUILIB"
ON ERROR IF !dlg% <> 0 THEN PROC_closedialog(dlg{}) : END
ON CLOSE IF !dlg% <> 0 THEN PROC_closedialog(dlg{}) : QUIT
PROC_static(dlg.static1{}, "Example dialog", 5, 5, 70, 10, 0)
REM PROC_static(struc.sub{}, text$, x%, y%, cx%, cy%, style)
PROC_pushbutton(dlg.button1{}, "Close", 30, 30, 45, 15, 0)
REM PROC_pushbutton(struc.sub{}, text$, x%, y%, cx%, cy%, style)
PROC_showdialog(dlg{}, "Example dialog", 100, 100, 100, 50, 8)
REM PROC_showdialog(struc{}, text$, x%, y%, cx%, cy%, font%)
REPEAT
Click% = FN_whichctrlclicked(dlg{})
UNTIL click% <> 0
PROC_closedialog(dlg{})
QUIT
1. Is this the sort of thing you might want to see in the main program (as opposed to the GUILIB)?
Assuming it's close:
2. I am unsure about how to deal with 'anonymous' structures in this way. Yes, I've read the help and more, but I'm still not sure. I don't understand how to 'add' more members to an already created one - if this is in deed how you are thinking of doing it.
If it's not close:
3. Sorry, I'm obviously missing the point from your spec.
Either way:
4. (1.4) "avoiding the need to allocate the memory in advance as is currently necessary with FN_newdialog()". What's the disadvantage of allocating space before the dialog members are created? Do we not allocate memory before events in other areas, such as DIM code% 255, text$(10), struc{ member% }; etc.
5. (1.3) "The same method of creating controls/widgets will be used for both dialogue boxes and other kinds of windows." Are you talking superficially, or the actual GUILIB coding for each control?
6. (1.4) "of storing information which the standard dialogue template has no means of holding". Such as?
7. (1.5) "Controls which can generate 'useful' notifications will take as one of the parameters a handler PROCedure". Such as [close] in the above LB example? If this a fixed format, will it not limit any requirement to use different PROCs/FNs in different circumstances, but by clicking the same button, or will/could this be an indirect pointer rather than a specific PROC/FN.
8. All of (2) I was in the process of producing in the DLGLIB, but I've put that on hold as it contains PROCs/FNs that relate to PROCs/FNs in WINLIB2, etc.
9. (3.1) "These will be similar to the existing PROC_showdialog() in WINLIB2 and FN_createwin() in MULTIWIN." Is this suggesting that whether it's a dialog box or independent window, the same PROC/FN is used?
There are other issues, but until I understand them to some extent, I'm unable ask appropriate questions about them.
Forgive the limited knowledge or understanding, and in deed the time it's taking. I unfortunately have other issues stopping me from concentrating wholeheartedly on this.
Matt
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #12 on: Dec 8th, 2013, 1:33pm » |
|
on Dec 8th, 2013, 1:03pm, Matt wrote:| 1. Is this the sort of thing you might want to see in the main program (as opposed to the GUILIB)? |
|
It's pretty close to what I had in mind. You've used an inappropriate syntax (dlg.static1{} where presumably you simply meant dlg{}) and you've used PROCs where I had expected FNs (how did you envisage returning the IDs?).
Quote:| I don't understand how to 'add' more members to an already created one - if this is in deed how you are thinking of doing it. |
|
You can't (at least, not without a memory leak). To the extent that I'd thought about it at all, I had imagined it would probably use a linked-list.
Quote:| What's the disadvantage of allocating space before the dialog members are created? |
|
The problem is that people don't, and often won't, read the documentation! A common report I receive is that their code is generating the "No room for dialogue template" error, and they haven't a clue what it means or how to fix it. It's tempting just to say RTFM, but it would be better to devise a library that automatically allocates the memory it needs.
Quote:| Do we not allocate memory before events in other areas, such as DIM code% 255, text$(10), struc{ member% }; etc. |
|
Yes, but in those cases you know ahead of time exactly how much to allocate; you don't need to 'guess'. With the dialogue template you either have to allocate far more memory than necessary, which is wasteful, or guess roughly how much you think it'll need and then increase it as necessary.
Quote:| (1.3) "The same method of creating controls/widgets will be used for both dialogue boxes and other kinds of windows." Are you talking superficially, or the actual GUILIB coding for each control? |
|
It's confusing for the user to have to use a different syntax for controls on a dialogue box compared with controls on a non-dialogue window. Even if the code in the GUILIB library needs to be different for the two cases, that's an implementation detail which ought to be hidden from the user. LB doesn't make any distinction - the syntax is identical in the two cases.
Quote:| 6. (1.4) "of storing information which the standard dialogue template has no means of holding". Such as? |
|
For example, a control may have an event associated with it, which fires when the control is clicked. The standard Windows dialogue template has nowhere to store that information.
Quote:| If this a fixed format, will it not limit any requirement to use different PROCs/FNs in different circumstances |
|
I'm open to alternative suggestions. The Liberty BASIC approach isn't ideal in this case, because each control can have only one associated event. Additional events, if any, are set up differently, using the WHEN command. But it's still better than what we have at the moment!
Quote:| (3.1) "These will be similar to the existing PROC_showdialog() in WINLIB2 and FN_createwin() in MULTIWIN." Is this suggesting that whether it's a dialog box or independent window, the same PROC/FN is used? |
|
Don't you think that's sensible? As I said above, LB makes no distinction between dialogues and non-dialogue windows, and I don't see how it is helpful to a user to force him to consider them as different kinds of 'animal'. They're all windows, after all.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #13 on: Dec 11th, 2013, 8:33pm » |
|
on Dec 8th, 2013, 1:33pm, Richard Russell wrote:| You've used an inappropriate syntax (dlg.static1{} where presumably you simply meant dlg{}) |
|
Yeah, I realised that, thanks. My mind was obviously still half way on VB.
Quote:| and you've used PROCs where I had expected FNs (how did you envisage returning the IDs?). |
|
Hmm. Yes, that would make sense. Unless you forced the PROC/FN to allocate a user-set ID, as we do at present.
Quote:| It's confusing for the user to have to use a different syntax for controls on a dialogue box compared with controls on a non-dialogue window. Even if the code in the GUILIB library needs to be different for the two cases, that's an implementation detail which ought to be hidden from the user. LB doesn't make any distinction - the syntax is identical in the two cases. |
|
Accepted, but how would the FN distinguish between a parent window and a dialog box if it's the same format? Wouldn't a parent window be a variable, e.g. @hwnd%, and the dialog box a structure, e.g. dlg{}? Or could you also use a structure for the parent window. (I appreciate that technically a dialog box is a parent window of its controls - maybe that's the way I should be thinking - hmmm.)
Quote:| For example, a control may have an event associated with it, which fires when the control is clicked. The standard Windows dialogue template has nowhere to store that information. |
|
Good example, although, with this one, I think there should be someway to disable/neutralize it to allow the program to offer its own direction if clicked.
I've been swatting up on structures, specifically anonymous, as it's something I've not used before.
Could the full structure of, say, a dialog box be something like dlg{ (ctrls%) [id%, hndl%,] x%, y%, cx%, cy%, other }?
If structures are not created using an 'init' routine, such as the current FN_newdialog(), then they will have to be created using the first pass of the creation of a control - wouldn't they? If this is the case, how would it know how many ctrls there are, or do I need to look at this a different way?
I can't really get any further until I sort out the structure issues.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #14 on: Dec 11th, 2013, 8:53pm » |
|
on Dec 11th, 2013, 8:33pm, Matt wrote:| Yes, that would make sense. Unless you forced the PROC/FN to allocate a user-set ID, as we do at present. |
|
That is a possibility. As I recollect, one of the unresolved issues from the Yahoo discussion was that very point.
Quote:| how would the FN distinguish between a parent window and a dialog box if it's the same format? |
|
I don't think it necessarily needs to. In the LB case you define all the child controls first, without specifying whether they will be hosted in a dialogue box or another kind of window, and then when you eventually open the parent window you say what type it is then.
Quote:| I appreciate that technically a dialog box is a parent window of its controls |
|
There's hardly any difference between a dialogue box and any other kind of window. The only one that immediately comes to mind is that the 'default' window procedure is DefDlgProg in one case and DefWindowProc in the other:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms645450.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633572.aspx
Quote:| If structures are not created using an 'init' routine, such as the current FN_newdialog(), then they will have to be created using the first pass of the creation of a control - wouldn't they? |
|
If you use a linked-list, as I suggested, then each control will create a new structure anyway - whether it's the first or not. That's the way it works in LBB: each control, and the parent window, has an associated structure which are linked together - with the parent window as the head of the list.
You are at a disadvantage because much of the code needed to do this already exists in LBLIB and wouldn't need much adaptation, but realistically you can't take advantage of that.
Richard.
|
|
Logged
|
|
|
|
sveinioslo
Developer
member is offline
Posts: 64
|
|
Re: GUILIB
« Reply #15 on: Dec 12th, 2013, 2:55pm » |
|
Maybe i should report my work with this GUILIB.
A few points are not according to the specs, but that can be fixed.
I was hoping to get phase 1 (winlib2+3+5) ready before christmas, but i dont think i will make it in time.
There is however enough ready to show a demo.
The following will mimic the look and behavior of DLGDEMO.BBC found in the examples folder.
http://fix24.net/bb4w/GUI_lib_demo.exe
http://fix24.net/bb4w/GUI_lib_demo.bbc
This is the relevant code:
Code: Dlg%=FNGUI_dialog("Dialogue box") : REM REM_out this line to place items in main window
Ed%=FNGUI_editbox("")
Ednum%=FNGUI_editbox_numeric(""): PROCGUI_crlf
Co%=FNGUI_combobox("")
Li%=FNGUI_listbox("") : PROCGUI_crlf
PROCGUI_vtabline(-24)
R1%=FNGUI_radio("Radiobutton 1"): PROCGUI_crlf
R2%=FNGUI_radio("Radiobutton 2")
Ch%=FNGUI_checkbox("Checkbox") : PROCGUI_crlf
PROCGUI_tab(44)
Ok%=FNGUI_button("Ok")
Cl%=FNGUI_button("Cancel")
IF Dlg%=0 THEN END : REM the following code will not run in main window yet !
Gr%=FNGUI_group("Group box",Ed%,Ch%)
PROCGUI_write(Ed%,"Text box")
FOR I%=1 TO 4 : PROCGUI_write(Co%,"Combobox "+STR$(I%)): NEXT I%
FOR I%=0 TO 3 : PROCGUI_write(Li%,"Listbox item "+STR$(I%)): NEXT I%
PROCGUI_set(R1%,0) : REM dummy data for radio
PROCGUI_set(Co%,0)
REPEAT
Sel%=FNGUI_waitfor(Dlg%)
UNTIL Sel%=Ok% OR Sel%=Cl% OR Sel%<100
IF Sel%=Dlg% THEN PRINT "Dialog closed" : END
IF Sel%=Cl% THEN PRINT "Cancel pressed" : PROCGUI_close(Dlg%) : END
PRINT "OK pressed, settings were:"'
PRINT "Text box contained ";FNGUI_read(Ed%)
PRINT "Number box contained ";FNGUI_read(Ednum%)
PRINT "Combobox selection was ";FNGUI_read(Co%)
PRINT "Listbox selection index was ";FNGUI_get(Li%)
IF FNGUI_get(R1%) THEN PRINT "Radiobutton 1 was checked" ELSE PRINT "Radiobutton 2 was checked"
IF FNGUI_get(Ch%) THEN PRINT "Checkbox was checked" ELSE PRINT "Checkbox was not checked"
PROCGUI_close(Dlg%)
END
As can be seen, i am trying to get the syntax down to the bare minimum.
Item creation is working in both main and dialog with the same syntax.
Items will be created in the window/dialog that is active.
Event handling, write and read is still under development.
Svein
Note: Put a REM in front of the first line listed here, and the items will be placed in main window.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #16 on: Dec 12th, 2013, 3:43pm » |
|
on Dec 12th, 2013, 2:55pm, sveinioslo wrote:| Maybe i should report my work with this GUILIB. |
|
I'm not sure that it makes any sense for two people to be working on it independently! Or have you and Matt been liaising without mentioning it here?
Quote:| As can be seen, i am trying to get the syntax down to the bare minimum. |
|
I don't understand the syntax of your example. How do you specify the positions and sizes of the controls? How do you specify the styles and extended-styles of the controls?
Quote:| Items will be created in the window/dialog that is active. |
|
I hope you are not relying on the use of global variables! Sharing global variables between the main program and a library isn't acceptable (second item listed here):
http://bb4w.wikispaces.com/Guide+to+writing+libraries
Richard.
|
|
Logged
|
|
|
|
sveinioslo
Developer
member is offline
Posts: 64
|
|
Re: GUILIB
« Reply #17 on: Dec 12th, 2013, 10:30pm » |
|
Quote:| I'm not sure that it makes any sense for two people to be working on it independently |
|
I did not know if anyone else where doing this, just happened to pop in and read this thread.
Quote:| I hope you are not relying on the use of global variables! |
|
No, just easier to use them in the development stage.
Quote:| How do you specify the positions and sizes of the controls? How do you specify the styles and extended-styles of the controls? |
|
The size and style are predefined and can be changed by PROCGUI_size(id%,cx%,cy%) and PROCGUI_style(id%,style%)
When i am writing code for a new dialog (using the original libraries), i will almost always start with more or less the same values, and then altering them afterwards.
The positioning is done the same way as you would write text to the screen.
You do not normally specify the position of the next character, you just send it to the screen knowing that it will land next to the previous one.
When you think the line is long enough, you send an CRLF, and then the next character will start from the left on a new line.
So i was thinking, why can't one do the same with items.
Ok, it's slightly more complicated, the items have both different width and height, but that's how it's done, and it's working :)
The dialog is of rubber type, it will expand as far as necessary.
There is also a fully automatic mode to position the items.
You just write your item list, and the software will try to fit them into a square.
Replace the demo code with this, and you will see how it's done.
Code: PROCGUI_slowdown
Dlg%=FNGUI_dialog("")
FOR I%=1 TO 100
a=FNGUI_button(STR$(I%))
NEXT I%
END
Svein
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #18 on: Dec 13th, 2013, 08:37am » |
|
on Dec 12th, 2013, 10:30pm, sveinioslo wrote:| I did not know if anyone else where doing this, just happened to pop in and read this thread. |
|
I have been asking for months for somebody to take an interest in helping to write GUILIB, but apart from some preliminary work by David Marples there were no takers. Following a recent repeat of my plea, Matt has offered to attempt it; he has asked for other people to help him. We have had worthwhile discussions about the design of the data structures which will form the core of the library.
If you have secretly been working on your own version of GUILIB, without telling anybody, that is unfortunate. But from your description it is so dissimilar to my published specification that I'm not sure how relevant it is anyway. I am looking for something which will provide the functionality of the existing WINLIB* libraries but with a user interface more like that provided by Liberty BASIC - not something radically different from either!
I would suggest that you and Matt hold discussions, either here or in private, to see whether some common ground can be established.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #19 on: Dec 14th, 2013, 05:33am » |
|
Hi Richard,
I've been looking at the linked lists code in Wiki to see if I can adjust it to suit the library routine. I've never used it before, so it was interesting to look at. However, there are a couple of issues with using it here that I can't figure out without major coding length.
The coding in Wiki sets the first% variable to the first link pointer during the setting up of the list. No problem there, in itself.
1. But if the list is being created through multiple entries into a FN, then this would need to be set as a PRIVATE variable, and the routine would have to recognize that it was the first link in the chain. The only way I can see of doing this is by checking !(^dlg{}+4) before DIMming the new structure. If the structure doesn't exist, the value is zero. If it is, the structure can be dimensioned and then the first% variable can be set. But the first% variable does need to be PRIVATE.
2. The bigger issue with the first link, as far as I can make out, is if there are multiple parent windows. In this case there would need to be multiple first% variables, (possible a separate linked list, or is this getting more complicated than it needs to be?). And the routine would have to recognize which parent window (e.g. prefs{}, setup{}, wnd{} etc.) is being used. Is there a way to distinguish between structures like this? I'm struggling to find a way.
Matt
Edit: Just realized that requesting the pointer to the structure in the FN - !(^dlg{} [+4] ) will give an independent one to any other. That could be used to sort out the last question I put.
Out of curiosity, before a structure is created, why can you deal with it by using requests such as =!(^dlg{}) but not =dlg.a% ? Does the first one treat the structure name 'dlg{' simply as a variable name at this stage?
|
| « Last Edit: Dec 14th, 2013, 07:13am by Matt » |
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #20 on: Dec 14th, 2013, 05:48am » |
|
on Dec 13th, 2013, 08:37am, Richard Russell wrote:I would suggest that you and Matt hold discussions, either here or in private, to see whether some common ground can be established.
|
|
I'm happy to colaborate. But I would suggest either on here (preferably), or privately with the *three* of us as you will moderate and possible install the finished library in v6.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #21 on: Dec 14th, 2013, 1:36pm » |
|
on Dec 14th, 2013, 05:33am, Matt wrote:| But if the list is being created through multiple entries into a FN, then this would need to be set as a PRIVATE variable |
|
That's not how I had envisaged it working. The whole point of the 'anonymous' structure - which gets passed to-and-from each function - is that any 'private state' is held in that structure, not in PRIVATE variables. This is discussed in the Guide to writing libraries in the section beginning "It will occasionally be necessary for two or more routines within a library to share information...".
You could even (although I don't know why you'd want to) create two or more quite independent dialogue templates 'at the same time' by interleaving the calls to the control-creation routines any way you like. The functions would be quite oblivious that this was happening.
Quote:| is this getting more complicated than it needs to be? |
|
It sounds very complicated to me - I'm a great believer in the KISS principle! PRIVATE variables are problematical for all sorts of reasons, and they are best avoided entirely or at least used as sparingly as possible. I certainly don't think it is appropriate for control-creation routines to be using them at all.
The LBB routines which perform the equivalent functions don't use any PRIVATE variables. They share their 'private state' by means of memory buffers, which are conceptually (and also in fact) structures, but because LB doesn't allow structures to be passed as parameters only a memory pointer (i.e. address) is passed.
Quote:| Out of curiosity, before a structure is created, why can you deal with it by using requests such as =!(^dlg{}) but not =dlg.a% ? |
|
I'm not sure I follow. "Before a structure is created" it doesn't have any members, so a syntax like dlg.a% is meaningless: you can deduce from it that there is a member called a% but not where in the structure it is (or, more specifically, its memory offset from the start of the structure). That depends on which member it is, and the size(s) of the preceding member(s), neither of which is known until after the structure has been DIMmed.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #22 on: Dec 14th, 2013, 3:35pm » |
|
on Dec 14th, 2013, 1:36pm, Richard Russell wrote:| I'm not sure I follow. "Before a structure is created" it doesn't have any members, so a syntax like dlg.a% is meaningless: you can deduce from it that there is a member called a% but not where in the structure it is (or, more specifically, its memory offset from the start of the structure). That depends on which member it is, and the size(s) of the preceding member(s), neither of which is known until after the structure has been DIMmed. |
|
Sorry. I'll explain better.
If you write PRINT a%, before creating the variable, you will get an error. If you create the variable first, a%+=0 for instance, the error will, obviously, not occur.
However, writing PRINT ^a% before creating the variable will produce a pointer. But to what? (The variable, it seems.) But a% has not yet been created, yet, or does the indirection '^' create the variable, itself?
Matt
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #23 on: Dec 14th, 2013, 3:55pm » |
|
on Dec 14th, 2013, 1:36pm, Richard Russell wrote:| That's not how I had envisaged it working. |
|
No, I didn't think you had.
Quote:| You could even (although I don't know why you'd want to) create two or more quite independent dialogue templates 'at the same time' by interleaving the calls to the control-creation routines any way you like. The functions would be quite oblivious that this was happening. |
|
So that means the control-creation routine needs to know which dialog box or window the control should be used in. The only way I can see, at the moment, of doing that is to check the pointer of the structure and use a look-up list / linked list, and then append it to that linked list. (In that case, no PRIVATE variable.  )
But I don't know what method to use to differentiate between the different parent windows.
And I still can't figure out how to find the first linked-list item without a pointer. Or am I missing something blindingly obvious?
Quote:| I'm a great believer in the KISS principle! |
|
(Me too. Ask the wife.  ) Just for the record I've never used PRIVATE variables.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #24 on: Dec 14th, 2013, 4:10pm » |
|
on Dec 14th, 2013, 3:35pm, Matt wrote:| does the indirection '^' create the variable, itself? |
|
Yes. That's documented under 'Creation of variables':
http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin2.html#creation
"Variables can be created in a number of ways... By using the 'address of' operator"
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #25 on: Dec 14th, 2013, 4:24pm » |
|
on Dec 14th, 2013, 4:10pm, Richard Russell wrote:| Yes. That's documented under 'Creation of variables': |
|
Missed that. Thanks.
|
|
Logged
|
|
|
|
|
