BBC BASIC for Windows
Developers' Area >> Future developments >> GUILIB
http://bb4w.conforums.com/index.cgi?board=developments&action=display&num=1387582817

GUILIB
Post by Matt 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
Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by Matt 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
Re: GUILIB
Post by admin 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:
  1. 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.

  2. 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.
Re: GUILIB
Post by Matt on Dec 2nd, 2013, 5:40pm

on Dec 2nd, 2013, 4:49pm, Richard Russell wrote:
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


I'm unable to read it. It produces an error page.

Matt
Re: GUILIB
Post by ady 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
Re: GUILIB
Post by admin on Dec 2nd, 2013, 8:50pm

on Dec 2nd, 2013, 5:40pm, Matt wrote:
I'm unable to read it. It produces an error page.

I said: "accessible only by 'Developers'"! Like anybody else, you can request to join that group, but I'm not going to open it up to everybody. The reasons are outlined here:

http://bb4w.conforums.com/index.cgi?board=announcements&action=display&num=1330441094

Richard.

Re: GUILIB
Post by ady 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.
Re: GUILIB
Post by admin 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.

Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by Matt 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
Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by Matt 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
Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by sveinioslo 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.




Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by sveinioslo 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


Re: GUILIB
Post by admin 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.

Re: GUILIB
Post by Matt 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?
Re: GUILIB
Post by Matt 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
Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by Matt 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
Re: GUILIB
Post by Matt 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. smiley )

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. wink ) Just for the record I've never used PRIVATE variables.


Re: GUILIB
Post by admin 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.
Re: GUILIB
Post by Matt 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.
Re: GUILIB
Post by admin 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). smiley

Richard.

Re: GUILIB
Post by Matt 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 smiley )

Matt
Re: GUILIB
Post by admin 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:
Where can I find this?

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.

Re: GUILIB
Post by Matt 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
Re: GUILIB
Post by admin 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.

Re: GUILIB
Post by Matt 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
Re: GUILIB
Post by admin 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. sad

Richard.
Re: GUILIB
Post by sveinioslo 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
Re: GUILIB
Post by Richey 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... rolleyes
Re: GUILIB
Post by Matt 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... rolleyes

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
Re: GUILIB
Post by admin 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.

Re: GUILIB
Post by DDRM 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
Re: GUILIB
Post by admin 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. sad

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.

Re: GUILIB
Post by DDRM 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
Re: GUILIB
Post by admin 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.

Re: GUILIB
Post by Matt on Jan 4th, 2014, 05:20am

ListView Section:

This is supposed to be part of the GUILIB, but I'm not sure if you want to make it a different thread. (If you do, I can copy and paste it to a new thread, therefore not losing the first message.)

I've created several routines that create, and manipulate a ListView in 'Report Style'. Rather than list all I've done (especially if the 'create' is no good) I'll deal with one section at a time.

Richard, is this something like you're after:

Code:
      REM TEST AREA
      INSTALL @lib$+"WINLIB5A"
      ON CLOSE PROC_closewindow(H%) : QUIT
      DIM hdr$(5), wid%(5), jst%(5)
      FOR I% = 0 TO 5
        hdr$(I%) = "Header " + STR$(I%)
        wid%(I%) = 120
        jst%(I%) = I% MOD 3
      NEXT
      H% = FN_lv_setup(@hwnd%, 0, 40, 800, 300, hdr$(), wid%(), jst%(), -1, &2000001)
      END
      REM /TEST AREA

      REM Create a standard List View. Returns the handle of the List View
      REM Perameters: h%         = parent window handle%,
      REM             x%, y%     = coordinates of the top left corner;
      REM             cx%, cy%   = width & height of the LV;
      REM             header$()  = header text array;
      REM             width%()   = column width array;
      REM             justify%() = column justification array;
      REM             lastcol%   = last column set (zero-based)
      REM             style%     = style of the LV
      REM LOCAL vars: LVCOLUMN{} = listview column structure
      REM             D%         = LV handle
      REM             C%         = column count
      REM             H$         = header string
      DEF FN_lv_setup(H%, X%, Y%, W%, V%, H$(), W%(), J%(), L%, S%)
      LOCAL LVCOLUMN{}, D%, C%, H$
      LVCF_FMT         = &1
      LVCF_WIDTH       = &2
      LVCF_TEXT        = &4
      LVCF_SUBITEM     = &8
      LVM_INSERTCOLUMN = &101B
      DIM LVCOLUMN{ mask%, fmt%, cx%, pszText%, cchTextMax%, iSubItem% }
      LVCOLUMN.mask%   = LVCF_FMT OR LVCF_SUBITEM OR LVCF_TEXT OR LVCF_WIDTH
      IF L% > DIM(H$(), 1) OR L% < 0 THEN L% = DIM(H$(), 1)
      SYS "InitCommonControls"
      D% = FN_createwindow(H%, "SysListView32", "", X%, Y%, W%, V%, 0, S%, 0)
      FOR C% = 0 TO L%
        H$                   = H$(C%) + CHR$(0)
        LVCOLUMN.fmt%        = J%(C%) MOD 3
        LVCOLUMN.cx%         = W%(C%)
        LVCOLUMN.pszText%    = !^H$
        LVCOLUMN.cchTextMax% = LEN(H$)
        LVCOLUMN.iSubItem%   = C%
        SYS "SendMessage", D%, LVM_INSERTCOLUMN, C%, LVCOLUMN{}
      NEXT
      = D% 


There is no structure created, unlike what we are trying to do with the other windows. Is creating a structure required on all the windows for the GUILIB?

Matt
Re: GUILIB
Post by admin on Jan 4th, 2014, 10:00am

on Jan 4th, 2014, 05:20am, Matt wrote:
Richard, is this something like you're after

It looks to have the right kind of feature-set. Have you thought about the issue of converting the column-width values from pixels to dialogue-box-units, which presumably will be necessary when the List View is hosted in a dialogue box?

Quote:
Is creating a structure required on all the windows for the GUILIB?

I suppose it depends on how you intend to deal with creating the List View in a dialogue box rather than in a regular window (see for example the BB4W 'Compile' dialogue, in which the 'Embedded files' list is a Report Style List View).

The assumption I've always made is that it will be necessary to store the information relevant to each control in some kind of temporary structure, and then when the parent dialogue box or window is eventually opened that stored information will be used to create the controls.

If you don't use a structure of some kind it's not clear to me how you can (easily) achieve a common syntax for creating a control in a dialogue and in a regular window, which is one of the features that GUILIB is expected to provide.

Richard.

Re: GUILIB
Post by Matt on Jan 10th, 2014, 07:35am

on Jan 4th, 2014, 10:00am, Richard Russell wrote:
Have you thought about the issue of converting the column-width values from pixels to dialogue-box-units, which presumably will be necessary when the List View is hosted in a dialogue box?

This is getting embarrassing, not to mention incredibly frustrating. I've never put a LV in a dialog box and, try as I might, I can't figure out a way to do it!! I know it's just another window, but I'm stuck. I've trawled through the Windows control library and through the LIBs, but I'm just not seeing what I need to.

HELP!

Matt

(Incidentally, are you having problems viewing your replies with the Preview button here?)
Re: GUILIB
Post by DDRM on Jan 15th, 2014, 3:40pm

Hi Folks,

Toys back in the pram smiley though they weren't thrown out for quite the childish reason you attributed to me.

I've posted on Wiggio another go, much closer to what you describe in the wiki, which might or might not be what you are looking for. All structures are now hidden under the bonnet, and don't need (or get) names.

A number of issues come to my mind:

1) I obviously haven't got the space calculation quite right, since I've had to add a fiddle factor...

2) I end up with a pointer to the structure used to define the dialogue box (wh%), and also a handle for the dialogue box (dlg%). In line with Richard's suggestion before Christmas I've moved towards using dlg% and id% for subsequent manipulations, but then I can't see how to get the routines to go back and change the contents of the structures. Effectively, the structures just get thrown away (but as far as I can see the memory not released) once the dialogue template is actually created. If I used wh% instead of dlg% I could modify the structure(s - including the control structures if needed, though I'd need to chase through the linked list), but it would be a bit slower and clunkier (though that would be hidden under the bonnet).

3) It seems to me that I need 3 instructions to create the DB now - one to initialise the structure, one to create the DB template, and then one to show it. I could combine the latter two, but I'd still want to be able to show/hide the DB again, so I'd still need the "showdialog".

Best wishes,

D
Re: GUILIB
Post by Andy Parkes on Jan 31st, 2014, 10:15pm

Hi Folks,

Over the past couple of days, I have made a stab at section 1 of Richard's GUILIB specification, specifically:

1.1, 1.2, 1.3, 1.4, 1.7

http://wiggio.com/yui/folder/stream_file.php?doc_key=qzoGwHPMw5YPmQHvlem1YJwv2VPYvWN4fAwoh5i5FIE=

The start of the file contains some code to demonstrate its use. I have made no attempt to include code to handle events, so if you run it, its best not to click on anything until its done. I think it succeeds in setting 'a' foundation for a simple unified interface for all window types and controls, but I've achieved this using brute force and ignorance. You'll see what I mean.

Theoretically, I could continue in this fashion and meet most of the specifications for GUILIB, but I think it would turn into the 'John Logie Baird' rather than the 'Marconi-EMI' of GUILIBs.

http://www.bbc.co.uk/programmes/p019d7fl

Thanks

Andy
Re: GUILIB
Post by admin on Feb 1st, 2014, 09:56am

on Jan 31st, 2014, 10:15pm, Andy Parkes wrote:
Over the past couple of days, I have made a stab at section 1 of Richard's GUILIB specification

Not content with three people (seemingly) independently working on GUILIB, we now appear to have a fourth!

Whilst the last thing I want to do is to curb enthusiasm, which is sorely lacking (not least on my behalf!), this is no way to run a software project! The idea was that GUILIB would be a collaborative effort; quite how the work might be farmed out I don't know - presumably there would be somebody (not me!) in overall control.

A prerequisite for a 'team' development is for the specification to be sufficiently detailed and complete that everybody knows what is being aimed for, and I don't think the existing spec achieves that.

So can I ask that Matt, Svein, David and yourself get your heads together, decide who is going to be in charge, update the spec (I would want to take a role in that) and then work out how to proceed from there?

If you, collectively, don't feel that a collaboration is possible I'm not sure how we should proceed. I don't want to be presented with several independent offerings from which I am expected to cobble together some kind of Frankenstein's monster of a library. wink

Richard.