BBC BASIC for Windows
« GUILIB »

Welcome Guest. Please Login or Register.
Apr 5th, 2018, 10:00pm



ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018.
Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.

If you require a dump of the post on your message board, please come to the support board and request it.


Thank you Conforums members.

BBC BASIC for Windows Resources
Online BBC BASIC for Windows documentation
BBC BASIC for Windows Beginners' Tutorial
BBC BASIC Home Page
BBC BASIC on Rosetta Code
BBC BASIC discussion group
BBC BASIC for Windows Programmers' Reference

« Previous Topic | Next Topic »
Pages: 1 2 3 4  Notify Send Topic Print
 veryhotthread  Author  Topic: GUILIB  (Read 616 times)
admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx 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.
User IP Logged

Matt
Developer

member is offline

Avatar




PM

Gender: Male
Posts: 210
xx 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
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx 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. sad

Richard.
User IP Logged

sveinioslo
Developer

member is offline

Avatar




PM


Posts: 64
xx 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
User IP Logged

Richey
New Member
Image


member is offline

Avatar




PM

Gender: Male
Posts: 35
xx 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... rolleyes
User IP Logged

Matt
Developer

member is offline

Avatar




PM

Gender: Male
Posts: 210
xx 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... 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
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx 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.
User IP Logged

DDRM
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 321
xx 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
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx 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. 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.
« Last Edit: Dec 20th, 2013, 2:07pm by admin » User IP Logged

DDRM
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 321
xx 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
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx 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.
User IP Logged

Matt
Developer

member is offline

Avatar




PM

Gender: Male
Posts: 210
xx Re: GUILIB
« Reply #41 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
User IP Logged

admin
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM


Posts: 1145
xx Re: GUILIB
« Reply #42 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.
User IP Logged

Matt
Developer

member is offline

Avatar




PM

Gender: Male
Posts: 210
xx Re: GUILIB
« Reply #43 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?)
User IP Logged

DDRM
Administrator
ImageImageImageImageImage


member is offline

Avatar




PM

Gender: Male
Posts: 321
xx Re: GUILIB
« Reply #44 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
User IP Logged

Pages: 1 2 3 4  Notify Send Topic Print
« Previous Topic | Next Topic »

| |

This forum powered for FREE by Conforums ©
Terms of Service | Privacy Policy | Conforums Support | Parental Controls