Author |
Topic: GUILIB (Read 615 times) |
|
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
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #26 on: Dec 14th, 2013, 4:25pm » |
|
on Dec 14th, 2013, 3:55pm, Matt wrote:| So that means the control-creation routine needs to know which dialog box or window the control should be used in. |
|
All it needs to know is what other controls will end up in the same dialogue box or window. It doesn't actually need to know which window that will be until it's eventually created.
Quote:| 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 |
|
The anonymous structure/linked-list associates all the controls, which will end up in the same window, together. Eventually it will also link those controls to the window itself, but that need only happen when it is eventually created.
Quote:| And I still can't figure out how to find the first linked-list item without a pointer. |
|
But you do have a pointer, because you've stored it in the anonymous structure (or it's the structure itself, meaning that an explicit pointer is not required, which is the way it works in LBB).
Quote:| Or am I missing something blindingly obvious? |
|
It's perfectly obvious to me, but then the code to do it is already written, tested and working (in LBB).
Richard.
|
| « Last Edit: Dec 14th, 2013, 4:48pm by admin » |
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #27 on: Dec 15th, 2013, 07:04am » |
|
on Dec 14th, 2013, 4:25pm, Richard Russell wrote:| But you do have a pointer, because you've stored it in the anonymous structure (or it's the structure itself, meaning that an explicit pointer is not required, which is the way it works in LBB). |
|
No. I'm still not getting it. In the Wiki linked list example, the pointer is continuously changed to the next link, but it remembers the first link, which is set (in first%) when the first link is created. With the GUILIB routine (and not using PRIVATE) each time it re-enters, it needs to know where that first structure link is. If it's just appending to the end of the list (which it could do, as the structure pointer to the previous members is present) then the routine that links/displays the dialog/window controls will have to find the first link. If this link is lost then the memory allocation of the structure members is lost. In the Wiki example, how would you find the first link if it were in a PROC/FN and not using PRIVATE?
The whole point of a linked list is that you can move around in it - including finding the first link.
Quote:| It's perfectly obvious to me, but then the code to do it is already written, tested and working (in LBB). |
|
Where can I find this?
My appologies if I seem too much of a novice, with this, but if I can't understand what you find obvious, then I'm not sure I'm the right man for the job - and that is frustrating. (May we both have patience )
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #28 on: Dec 15th, 2013, 09:43am » |
|
on Dec 15th, 2013, 07:04am, Matt wrote:| No. I'm still not getting it. In the Wiki linked list example, the pointer is continuously changed to the next link, but it remembers the first link, which is set (in first%) when the first link is created. |
|
That's just one way to do it. You can avoid it either by dynamically searching for the end of the list each time (which is relatively inefficient, but that doesn't matter in the case of GUILIB) or by adding your new node at the head of the list rather than the tail (which is very fast, but ends up with the items in reverse order). Either way you only need a pointer to the head of the list, and if that happens to be the anonymous structure itself you don't need a pointer at all!
Quote:| In the Wiki example, how would you find the first link if it were in a PROC/FN and not using PRIVATE? |
|
As I said before, passing an anonymous structure is equivalent to PRIVATE. It's an alternative way of storing a 'private state', and has the advantage that there can be many concurrent 'private' states (one for each structure).
Quote:
You can't - it's unlikely that I'll ever release LBLIB (except in its crunched form LBLIBC of course). And even if I did, it's not commented and probably wouldn't make much sense.
Quote:| My appologies if I seem too much of a novice, with this. |
|
There will be bits of GUILIB that need a highly experienced programmer, particularly the assembly language parts, and I had always anticipated doing those myself. But linked lists are conceptually very simple, so I wouldn't expect to you have any difficulty with those. If you need to refer to the Wiki, it might suggest your understanding of fundamental Computing Science principles is a bit weak.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #29 on: Dec 15th, 2013, 2:31pm » |
|
on Dec 15th, 2013, 09:43am, Richard Russell wrote:| or by adding your new node at the head of the list rather than the tail (which is very fast, but ends up with the items in reverse order). |
|
Surprisingly, this idea had actually occurred to me. Doing it this way (to my mind) means that you only need to set the new link to point to the second rather than follow all the way through the links. The structure header always contains the pointer to the first link. Having the controls entered into the list in reverse order should not be a problem - they can always be reversed at show time. (The reason I hadn't mentioned it before was firstly, I didn't think it was the normal route, and secondly, I'd forgotten until you mentioned it.)
Another thought that occurred to me was: would it be a waste of space to have the first link pointer placed in each link? Whichever link you looked at, the first link would always be known.
Quote:| There will be bits of GUILIB that need a highly experienced programmer, particularly the assembly language parts, and I had always anticipated doing those myself. |
|
That's a little more comforting.
Quote:| If you need to refer to the Wiki, it might suggest your understanding of fundamental Computing Science principles is a bit weak. |
|
That's probably a bit of an understatement - especially when it comes to this area. I've been using BBC BASIC, in its various forms, on and off for the past 30 odd years and I still have problems with some of the basics. (Although structures are relatively new to BBC BASIC, linked lists have always been around. I remember my dad using one specifically in a program he was writing.)
Are there any online courses that might be helpful to me, that you recommend? I've thought about doing a computer / computing science course for many years, but there's nothing in my area.
Incidentally, if you seriously think I'm not the right person for this, please say! My chin's big enough. I'm happy to drop it and concentrate on things that I do know, but I'm also happy to push on with this! Though the question might be: are you happy for me to push on with this?
Matt
|
|
Logged
|
|
|
|
|
