Author |
Topic: GUILIB (Read 624 times) |
|
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
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #30 on: Dec 15th, 2013, 4:14pm » |
|
on Dec 15th, 2013, 2:31pm, Matt wrote:| Having the controls entered into the list in reverse order should not be a problem - they can always be reversed at show time. |
|
Possibly, but reversing the order of the items is a messy operation (unless it's a doubly-linked list!) and - even though you only need to do it once - could be less efficient than following the links to the end for each control. The code in LBLIB which follows the links is very simple and pretty fast:
Code: WHILE E%!72 E% = E%!72 : ENDWHILE
Quote:| Would it be a waste of space to have the first link pointer placed in each link? |
|
Clearly it is a waste, but like everything else it's a matter of degree. Anyway, in this particular case I don't see how it would help you.
Quote:| are you happy for me to push on with this? |
|
It's not really my decision. I would have said "if you don't do it, probably nobody will" but things have become more complicated since Svein's admission that he's been working on a version of GUILIB himself. Although it seems to have an interface quite different from what I was expecting, and wanting, the code itself may be useful.
Unfortunately Svein either isn't regularly monitoring this forum, or doesn't want to be involved in a collaborative project, because he is not contributing to the discussion (and I presume he hasn't contacted you privately either).
So I do feel we are in rather a state of limbo as far as GUILIB is concerned. I'm depressed enough about BB4W as it is, and I don't really want to have to worry about GUILIB on top of everything else.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #31 on: Dec 15th, 2013, 4:33pm » |
|
on Dec 15th, 2013, 4:14pm, Richard Russell wrote:| I'm depressed enough about BB4W as it is, and I don't really want to have to worry about GUILIB on top of everything else. |
|
In that case, I would suggest that GUILIB is put on the back burner for the moment, unless anyone else is interested. I also have other things that are taking up time and (emotional) energy.
The current state of play with BB4W, in your eyes, may not be perfect or ideal, but it does work damn well as far as I can see.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #32 on: Dec 15th, 2013, 5:14pm » |
|
on Dec 15th, 2013, 4:33pm, Matt wrote:| In that case, I would suggest that GUILIB is put on the back burner for the moment |
|
As I think you've said yourself, it probably wouldn't make much sense to release version 6.00a of BB4W without GUILIB, but since I haven't even released 5.95a yet we have some time before it becomes critical. On the other hand the longer I wait the more my faculties deteriorate. 
Richard.
|
|
Logged
|
|
|
|
sveinioslo
Developer
member is offline
Posts: 64
|
|
Re: GUILIB
« Reply #33 on: Dec 16th, 2013, 09:20am » |
|
I started to think about a big GUI library i Feb 2012. (after i had written an incompatible and therefore useless menu library)
But i did not then have the knowledge nor any idea of how to solve it.
I got an idea two months ago, but i had no idea if it would work, or if i now had enough knowledge.
I bought BB4W specifically to learn about GUI and windows, i had no previous experience or knowledge.
Once i started writing the code, i got carried away by the fact that it seems to work and that i finally could understand some of the MSDN pages.
I am glad i did not try to explain this idea with my limited knowledge of english, no one would understand, and i would not be tempted to try to code it anyway, and i would not have the knowledge i now have.
You did not like this idea, ok, fine by me, but i still think there is something to it.
The question is how to implement it in a usable format.
The full_auto mode i showed you, was intended for early development stage of writing a new program, when the number/type of items is unclear and their position in a dialog is of no importance.
To keep the focus on the problem one are solving, rather than what it might look like.
I will continue to develop my idea, and Matt will benefit from continuing with his work.
Unless he already have all the knowledge necessary.
Sorry if i inconvenienced you.
Svein
|
|
Logged
|
|
|
|
Richey
New Member
member is offline
Gender:
Posts: 35
|
|
Re: GUILIB
« Reply #34 on: Dec 19th, 2013, 11:29pm » |
|
It would be shame if it is put on hold.
Easy GUI is one of the things that I find attractive about Liberty BASIC; I'm sure GUILIB is one of the key things that BB4W needs going forward.
Is there some way Matt and Svein could work together and share the load? I'm a novice myself but I'm willing to help out in any way I can... 
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #35 on: Dec 20th, 2013, 10:21am » |
|
on Dec 19th, 2013, 11:29pm, Richey wrote:| Is there some way Matt and Svein could work together and share the load? I'm a novice myself but I'm willing to help out in any way I can... |
|
As I stated before, I'm happy to collaborate.
However:
1. As far as I understand it, Svein's project is too far removed from Richard's spec not to require a significant rewrite (which he may well be willing to do), although he's said little about it.
2. Just like Richard there are other things going on that require attention that, at best, might slow the project down. (Maybe I should have thought of that when I initially said I'd do something, but I didn't, and I hadn't realised just how much knowledge and inspiration I lacked.
3. As I said to Richard, I'm beginning to think that I'm just not up to it. If anyone (including Richard) can hack me asking, sometimes, quite stupid/novice questions, I'm happy(ish) to return to it.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #36 on: Dec 20th, 2013, 10:56am » |
|
on Dec 20th, 2013, 10:21am, Matt wrote:| As far as I understand it, Svein's project is too far removed from Richard's spec not to require a significant rewrite |
|
The interface is significantly different from what I had in mind, but it may be that the underlying code could be adapted.
Quote:| Just like Richard there are other things going on that require attention that, at best, might slow the project down. |
|
I have already abandoned any possibility of GUILIB being ready for the release of BB4W v5.95a, so that takes the pressure off somewhat.
Quote:| As I said to Richard, I'm beginning to think that I'm just not up to it. |
|
I'm sure you would be more than capable of doing some of it, it's just unfortunate that you got bogged down in the detail of linked lists.
If you are finding the control-creation aspect difficult to get your head around, why not concentrate on some of the other features needed by GUILIB? For example once the controls have been created and the window/dialog opened, there needs to be a set of procedures and functions for interfacing with it (writing to controls, reading from controls, hiding/disabling/moving controls etc.). Some controls, notably text boxes, are going to need an extensive set of associated commands if we are to match what Liberty BASIC offers:
http://www.libertybasicuniversity.com/lb4help/87GG0ZE.htm
Perhaps you could take David Marples' existing code and extend it:
http://groups.yahoo.com/neo/groups/bb4w/files/Libraries/Potential%20winlib2%20extensions.bbc
Richard.
|
|
Logged
|
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: GUILIB
« Reply #37 on: Dec 20th, 2013, 11:42am » |
|
Hi Folks,
I promised myself I wouldn't post any matter of opinion, because it usually ends up causing both Richard and me excessive amounts of grief, but I don't want Matt going off down what I suspect might be a blind alley.
I've been thinking about Richard's proposal to use anonymous structures for the window definitions, and a linked list of structures for the controls therein. Here's my attempt to implement something like that:
http://wiggio.com/yui/folder/stream_file.php?doc_key=gI2BIxMHDNFJmKNKLe+Fji0Rf8qyeRxVl/X09+7QFe8=
Yes, I know the variable and subroutine naming conventions are all over the place. It's partly because during development I have sometimes had several versions of things working at the same time.
At the moment it covers most of WinLib2 (from which lots of the code is taken), but I know some amendments will be needed to cover Winlib5 (I think I'll need to add at least one field to the window structure, and a GUIInit routine to set up a structure for the main window). I wanted to get that done before I posted it, but (a) I wanted to pre-empt too much misplaced effort by Matt and (b) there are some things that I don't think are quite right, and I'd like to sort them out before spending too much time on it.
As you'll see from the two "add-on" routines at the bottom, I propose to pass the control's structure, rather than the dialogue handle and ID (both are held within the structure). If we want to use this pattern, it seems sensible to go for it straight away rather than following the model in my previous "potential extensions".
So the main questions are:
1) Is that the kind of thing you had in mind, and if so, does this look like a reasonable attempt at it?
2) Is there a better way to handle the linked list of structures than my "pass a pointer and then go read it out of memory", which has the risk that any changes in the structure format might cause a complete screw-up if I don't update it everywhere?
Best wishes,
D
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #38 on: Dec 20th, 2013, 12:53pm » |
|
on Dec 20th, 2013, 11:42am, DDRM wrote:| I don't want Matt going off down what I suspect might be a blind alley... I wanted to pre-empt too much misplaced effort by Matt |
|
My suggestion to Matt (did you see it?) was to concentrate on an entirely different area of GUILIB's functionality and not to worry about the control creation aspect. That should have avoided any misplaced effort on his part.
In any case we seem to have ended up with three, independent and incompatible, versions of the control-creation code already: mine (in LBLIB), Svein's (in his version of GUILIB) and now yours. I can't believe that makes any sense: a collaborative approach should be about sharing the work, not duplicating it!
Edit:
Quote:| As you'll see from the two "add-on" routines at the bottom, I propose to pass the control's structure |
|
I hadn't anticipated that an individual control's structure would be visible outside the library - wouldn't that mean every control having its own unique structure name?
Quote:| 1) Is that the kind of thing you had in mind, and if so, does this look like a reasonable attempt at it? |
|
I don't expect to be able to find the time to look at it for quite some while, sorry. I am having to manage a domestic crisis at the same time.
Quote:| 2) Is there a better way to handle the linked list of structures than my "pass a pointer and then go read it out of memory, which has the risk that any changes in the structure format might cause a complete screw-up if I don't update it everywhere?" |
|
Without actually studying your code I don't really understand the question. If it's based on the Wiki article I don't see why changing the structure format would have such consequences - the Wiki routines assume only that the structure contains a member link% somewhere, not its position nor what other members there may be.
Richard.
|
| « Last Edit: Dec 20th, 2013, 2:07pm by admin » |
Logged
|
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: GUILIB
« Reply #39 on: Dec 20th, 2013, 3:45pm » |
|
Hi Richard,
Yes, I saw your comment to Matt - that's why I posted my code. My approach means constructing those simpler routines to take the structure, so doing the way I did it in my proposed extensions would then need further modification.
I'd missed your article on doing a linked list with anonymous structures. Even after a quick look I still don't understand how you can refer to bits of a structure when you know nothing about it. I'll need to sit and have a think about it.
Yes, my approach means creating a structure for each control, but I couldn't see an automatic way of doing it. All the creation is done behind the scenes. The spinoff is that you can directly access things like the text field (assuming they are kept up to date by the library). I can see that it's an issue if you want to make a whole batch of controls in a loop, for example.
Of course collaboration is the way forward, though you haven't released your code, Matt has concluded that he isn't ready to produce any, and you had already suggested that Svein's wasn't going in the right direction. Clearly mine isn't either, so I won't waste more time on it, except perhaps for my own amusement.
I'm sorry to hear about your domestic crisis, and I hope it is satisfactorily resolved in time for you to have a nice Christmas.
Best wishes,
David
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #40 on: Dec 20th, 2013, 4:48pm » |
|
on Dec 20th, 2013, 3:45pm, DDRM wrote:| Yes, my approach means creating a structure for each control, but I couldn't see an automatic way of doing it. |
|
My concern is that it could be rather unmanageable in a program with multiple dialogues. For example if you used a structure CancelButton{} in one dialogue you wouldn't want to use the same structure name in another dialogue (and indeed you couldn't, if you wanted to declare all the dialogues at the start, which is my habit).
So you might end up with a CompileDialogue{} containing a CompileDialogueCancelButton{}, and before long all that name mangling becomes quite a mess. I can't really see what is wrong with identifying a control by a pair of values (one which identifies its parent dialogue, and the other the control within that dialogue), which is after all how it works in both C and Liberty BASIC. If it ain't broke, don't fix it.
Quote:| The spinoff is that you can directly access things like the text field |
|
You can't, whilst at the same time remaining an 'anonymous' structure! By definition, you can only access individual members within the library, not in the calling program.
Quote:| Of course collaboration is the way forward, though you haven't released your code |
|
There is no code I can sensibly release. The code in LBLIB neither meets the requirements, as it stands (Liberty BASIC doesn't allow you to pass a structure as a parameter) nor would it make sense to anybody else, out of context and with no comments. It could form the basis of a workable system but only with substantial modification.
Quote:| Clearly mine isn't either, so I won't waste more time on it, except perhaps for my own amusement. |
|
Is that not what is coloquially described as 'throwing your toys out of the pram'? I can certainly understand if you are frustrated that I have identified flaws in your proposal, but you chose to rush ahead into coding without first describing what you had in mind.
A better approach might have been to 'flesh out' my written specification with more detail. Ideally it would be desirable for all interested parties to have the opportunity to comment on the proposed GUILIB user interface before any code is written.
Or am I being naïve in expecting a 'professional' methodology to be adopted?
Richard.
|
|
Logged
|
|
|
|
|
