Author |
Topic: GUILIB (Read 612 times) |
|
Matt
Developer
member is offline
Gender: 
Posts: 210
|
 |
GUILIB
« Thread started on: Dec 1st, 2013, 04:33am » |
|
To all.
OK. I'm happy to have a go at producing some form of GUILIB, but I'm definitely going to need help, as I'm far from an expert programmer. Is there anyone out there who is happy to collaborate with me, either on here or through e-mail? Richard's doing his best elsewhere, so I don't think it would be fair on him. If we want BBCW to be promoted, it needs new input from all of us.
Matt
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #1 on: Dec 1st, 2013, 07:25am » |
|
on Dec 1st, 2013, 04:33am, Matt wrote:| OK. I'm happy to have a go at producing some form of GUILIB, but I'm definitely going to need help, as I'm far from an expert programmer. |
|
I have always envisaged GUILIB to consist largely of existing code from the current libraries (principally WINLIB*), so it shouldn't be a case of writing a lot of code from scratch. Unquestionably I would need to contribute some of it, which I am happy to do.
Also don't forget that David Marples has already made a start on it, so you'll probably want to factor in some of his code.
If you can get it to a stage where it supports all the existing functionality from the WINLIB* libraries I can add support for event handling and custom graphics controls, which will be adapted from existing code in LBLIB.
Good luck!
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #2 on: Dec 1st, 2013, 10:02am » |
|
I have updated the GUILIB specification to version 3:
http://www.bbcbasic.co.uk/bbcwin/guilibspec3.txt
The spec was discussed at some length on the Yahoo! group so I hope it won't be necessary to revisit it to any great extent.
Some knowledge of Liberty BASIC will be very helpful to anybody contributing to GUILIB, but not essential.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #3 on: Dec 2nd, 2013, 4:28pm » |
|
on Dec 1st, 2013, 10:02am, Richard Russell wrote:| I have updated the GUILIB specification to version 3 |
|
That's useful, thanks.
Looking more closely at the libraries indicated, and, as you know, having little knowledge of M/C, is there any reason apart from perhaps speed that you use it.
WINLIB:
1. FN_createstatusbar
- CreateStatusWindow (which now appears to be obsolete) is called.
- CallWindowProc
2. FN_createtoolbar
- CreateToolbarEx is called
- CallWindowProc
Can these not be called through SYS functions?
Quote:| Some knowledge of Liberty BASIC will be very helpful to anybody contributing to GUILIB, but not essential. |
|
I have virtually no knowledge of LB, so I need to investigate this.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #4 on: Dec 2nd, 2013, 4:49pm » |
|
on Dec 2nd, 2013, 4:28pm, Matt wrote:| having little knowledge of M/C, is there any reason apart from perhaps speed that you use it. |
|
As far as I remember, everywhere assembler code is used it is essential. The two main reasons why it is likely to have been used are:
To implement the message pump for the dialogue box. It is essential that the message pump calls the IsDialogMessage API, which the one built into BB4W doesn't.
To execute some API functions in the context of the GUI thread, rather than the interpreter's thread. Some API's (like SetFocus) are thread-sensitive and won't work if called from the wrong thread. Quote:| I have virtually no knowledge of LB, so I need to investigate this. |
|
As I said, it's not essential. But since the entire motivation for the GUILIB library stemmed from things being so much easier to do in LB, it would provide valuable background.
I assume you've read this post, which started the whole thing off (accessible only by 'Developers'):
http://bb4w.conforums.com/index.cgi?board=developments&action=display&num=1330539990
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: GUILIB
« Reply #5 on: Dec 2nd, 2013, 5:40pm » |
|
on Dec 2nd, 2013, 4:49pm, Richard Russell wrote:
I'm unable to read it. It produces an error page.
Matt
|
|
Logged
|
|
|
|
ady
Junior Member
member is offline
Posts: 55
|
|
Re: GUILIB
« Reply #6 on: Dec 2nd, 2013, 6:08pm » |
|
I assume you've read this post, which started the whole thing off (accessible only by 'Developers')
If we're all going to get involved should we not all have access to the things we need?
Or is there a valid reason for secret squirrel zones?
(I'm aware of coding community politics for instance)
While I'm no developer there's bound to be a few brain-dead time consuming tasks us lesser mortals can do in a project this big
|
|
Logged
|
|
|
|
ady
Junior Member
member is offline
Posts: 55
|
|
Re: GUILIB
« Reply #8 on: Dec 3rd, 2013, 12:40am » |
|
I tried to send you a message Richard
Richard Russell doesn't work
The site software removes the space
------------------------
An Error Has Occurred!
User RichardRussell does not exist. You have mistyped their username. Please hit back and try again.
|
| « Last Edit: Dec 3rd, 2013, 12:48am by ady » |
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #9 on: Dec 3rd, 2013, 01:54am » |
|
on Dec 3rd, 2013, 12:40am, ady wrote:| I tried to send you a message Richard |
|
I don't know what you were attempting to do, but it works correctly if you click on either the PM or Email icon (to the left of this text, if you are viewing normally rather than via the 'last 10 posts' search results).
Quote:| The site software removes the space |
|
I think you are getting muddled between Username, which cannot include spaces, and Name, which can (on your profile page this is described as 'the displayed name that people will see'). They can be entirely different.
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: GUILIB
« Reply #10 on: Dec 5th, 2013, 1:36pm » |
|
on Dec 1st, 2013, 04:33am, Matt wrote:| OK. I'm happy to have a go at producing some form of GUILIB, but I'm definitely going to need help |
|
Is this project proceeding, or has it been abandoned before even being started?
Richard.
|
|
Logged
|
|
|
|
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
|
|
|
|
|
