Author |
Topic: The future of BBC BASIC for Windows (Read 246 times) |
|
DDRM
Administrator
member is offline
Gender: 
Posts: 321
|
 |
Re: The future of BBC BASIC for Windows
« Reply #19 on: Mar 14th, 2012, 10:05am » |
|
Hi Richard,
I guess it could be a bit like OOP, but that wasn't really what I had in mind (I don't want to encapsulate the methods with the data as an object) - I envisioned a set of functions and procedures with a "BB4W feel" to them, more like your second option:
Code:PROC_SetText(hctrl%, text$)
In this particular case, as you say, it is largely cosmetic, but PROC_ReadText will be a bit more complicated (though still given in the manual), especially for multi-line dialogue boxes, and other things are more complicated still.
In VB you can change the size/position/characteristics of windows and controls directly, in a similar way, and it would be nice to be able to do this in BB4W, too.
My “level of abstraction” was the idea that you could have ?an array of structures? (size set when you call GUILibInit) in the background that stored the details for each control when it was created. For example, it would store which window/dialogue box handle it was associated with, so you don’t need to ask for hdlg%, and what control type it is, so that the routines can handle them appropriately. Of course it would also need to store content, any constraints (bounds for scroll bars etc), position, size, style, etc.
The idea would be that to access/change information relating to a control, you would use the appropriate function or procedure, with either the id% or a more user-friendly alias: “client_name”; again the alias would be stored in the structure and looked up when required. Alternatively, and faster I presume, someone cleverer than me could write a utility [pedant mode] should that be AN utility? [/pedant mode] to convert all the aliases to their equivalent IDs, a la the Windows constants utility.
Using an alias might actually require the parameter to be a quoted string, which is a bit ugly: it would be nicer if you could treat it like a variable name, but I’m not sure I could disentangle that without causing a “no such variable” error. Maybe you could...
Would it be possible/useful/desirable to cause controls which need initialising AFTER a dialogue box is shown to have that happen automatically with PROC_showdialogue? The relevant information could be provided when the control is first created, and then PROC_showdialogue could look up the associated controls, and initiate them as required?
As you have said, all these things CAN be done in BB4W, but a lot of people seem to be scared of even CONSIDERING using SYS calls, even when it is a straight cut and paste from the manual. It’s largely about wrapping these complexities up in a familiar, consistent form.
Hope that makes some sort of sense....
D
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #20 on: Mar 14th, 2012, 2:49pm » |
|
on Mar 14th, 2012, 10:05am, DDRM wrote:| I guess it could be a bit like OOP |
|
VB is Object Oriented.
Quote:| In VB you can change the size/position/characteristics of windows and controls directly, in a similar way, and it would be nice to be able to do this in BB4W, too. |
|
I have never programmed in VB, so can you give an example of the sort of syntax you have in mind? Changing the size/position/style of a control after a dialogue box has been opened is not something I had anticipated supporting (other than via direct API calls).
Quote:| For example, it would store which window/dialogue box handle it was associated with, so you don’t need to ask for hdlg%, and what control type it is, so that the routines can handle them appropriately. Of course it would also need to store content, any constraints (bounds for scroll bars etc), position, size, style, etc. |
|
Are you proposing dispensing with the conventional dialogue box template and creating the dialogue box in an alternative, non-standard, way? Admittedly that's exactly what LBB does, but I hadn't envisaged GUILIB departing so radically from the 'norm'.
Quote:| Would it be possible/useful/desirable to cause controls which need initialising AFTER a dialogue box is shown to have that happen automatically with PROC_showdialogue? |
|
What would be the advantage?
Quote:| The idea would be that to access/change information relating to a control, you would use the appropriate function or procedure, with either the id% or a more user-friendly alias: “client_name” |
|
Because it will always be necessary to do some things using direct Windows API (SYS) calls - that's inevitably the case in both VB and LB too - it will be important to ensure that the design of any GUILIB library doesn't make that more difficult than it needs to be. That suggests to me that it will always be better to refer to controls in ways that Windows understands - i.e. handles and/or IDs - rather than some BB4W-specific alias notation.
Quote:| Hope that makes some sort of sense.... |
|
Because of my lack of knowledge of Visual Basic many of the concepts you have described are unfamiliar to me. Can you perhaps illustrate them with some examples in a suggested BB4W syntax?
Richard.
|
|
Logged
|
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: The future of BBC BASIC for Windows
« Reply #21 on: Mar 15th, 2012, 3:33pm » |
|
Hi Richard,
Quote:| I have never programmed in VB, so can you give an example of the sort of syntax you have in mind? |
|
here’s a clip in VB:
Code:
Form4.Left = Form2.Left
Form4.Top = Form2.Top + Form2.Height
Form4.Visible = True
drawgraphs
calclanes
sumlanes
inited = True
Form3.Left = Form2.Left + Form2.Width
Form3.Top = Form2.Top
Form3.Visible = True
Here I have read a picture of (unknown) size into form2 and displayed it, and I can then position form4 beneath it, and form 3 to the right of it. Form4 will contain some densitometry data from the picture (of an electophoresis gel), while form3 is the controls for subsequent processing (adjusting lane positions, etc).
Quote:| Changing the size/position/style of a control after a dialogue box has been opened is not something I had anticipated supporting (other than via direct API calls). |
|
In another program, I changed the size of the form dynamically to hide or reveal some of the controls - effectively an "easy" or "advanced" interface. By changing the control.visible parameter you can also hide or reveal controls. I think this is really convenient. I guess it is pretty simple to hide or show components, as it is windows, so it would be a pretty thin wrapper!
Quote:| Are you proposing dispensing with the conventional dialogue box template and creating the dialogue box in an alternative, non-standard, way? Admittedly that's exactly what LBB does, but I hadn't envisaged GUILIB departing so radically from the 'norm'. |
|
No, I thought creating the dialogue box and the controls would be essentially unchanged: the only difference would be that the functions creating them would stick the data into an array of structures, so that subsequent calls to associated functions could look up the data they needed.
Quote:| What would be the advantage? |
|
[of automatically initialising controls when a dialogue box is made visible]. Well, you could set everything up in one place at one time.
Quote:| Because it will always be necessary to do some things using direct Windows API (SYS) calls - that's inevitably the case in both VB and LB too - it will be important to ensure that the design of any GUILIB library doesn't make that more difficult than it needs to be. That suggests to me that it will always be better to refer to controls in ways that Windows understands - i.e. handles and/or IDs - rather than some BB4W-specific alias notation. |
|
I think that’s probably right, and of course all the windows controls would still have handles/IDs. I just think it’s easier to remember that a control is called “client_name” rather than that its ID is 103. It wouldn’t be either/or, and indeed you would probably want to have equivalent functions:
name$=FN_GUI_GetTextN(“client_name”)
name$=FN_GUI_GetText(103)
Quote:| Because of my lack of knowledge of Visual Basic many of the concepts you have described are unfamiliar to me. Can you perhaps illustrate them with some examples in a suggested BB4W syntax? |
|
I’ll try and do a small example, but I can’t promise it today (I have a large chunk of a draft project to read for a student I’m seeing tomorrow morning...).
Best wishes,
D
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #22 on: Mar 15th, 2012, 6:05pm » |
|
on Mar 15th, 2012, 3:33pm, DDRM wrote:
I was hoping for some proposed BBC BASIC syntax. Only in an OO language will a simple 'assignment' like:
Code:
have an 'action'. In BBC BASIC it fundamentally cannot do anything other than to set the variable 'Form4.Left' to a new value.
Quote:| I guess it is pretty simple to hide or show components, as it is windows, so it would be a pretty thin wrapper! |
|
I cannot see the point of thin wrappers which add no functionality; to me they are just a means of obfuscating the Windows API. If the user learns how to do something by calling the Windows API directly it's a valuable skill which will serve him well if he advances to using another language, like C++. On the other hand learning a BB4W-specific syntax is a dead-end; if he moves to another language he will have to forget it and start again from scratch.
Quote:| No, I thought creating the dialogue box and the controls would be essentially unchanged |
|
That implies quite a lot of data duplication (parameters of controls would have to go into the dialogue box template and into your 'structures'). I'm always uneasy about duplication of this sort; it's inelegant and you risk obscure side-effects if the two copies get out-of-step.
I think this thread has come to the end of the road. My thanks to everybody who has taken the trouble to contribute.
Richard.
|
|
Logged
|
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: The future of BBC BASIC for Windows
« Reply #23 on: Mar 28th, 2012, 10:48am » |
|
Hi Richard,
I know you have declared this strand closed, but I have continued to have a bit of a play at the kinds of things I was interested in.
I started by looking at modifying the dialogue box template directly, as you implied, starting with Winlib2 as a teaching aid, but I have strayed away from that idea, because what I want is to be able to manipulate the dialogue box on the fly - I often use a dialogue box as a controls window, and leave it open all the time, but I may wish to be able to provide a simpler or more complex interface, depending on context.
I agree with you to some extent about providing very thin wrappers to obscure the API from the user, but I thought that the discussion started off by acknowledging that one could do virtually anything you wanted to in BB4W, but that many people were scared to do so, and we wanted to make it more approachable. A further counter-argument is that by providing them with a library (the code of which they can inspect) they can use it easily if that's all they want, or they can use it as a teaching aid, to see (a) how easy it is, and (b) have a sample of what to do. For example, the scaling of locations in dialogue box units is straightforward once you understand how to do it, but it took me quite a long time (even after I'd found Michael Hutton's posts on the Yahoo forum, which suggest he had also banged his head on it for a while). Another thing I found tricky was finding the handle for the controls: once I knew how to do it, I found that it is in fact in the manual, but it wasn't obvious to me.
I have posted a file called "potential winlib2 extensions.bbc" in the libraries section of the files section of the yahoo forum. This is essentially a testbed, but includes a set of small procedures and functions that I think might be more generally useful.
The program in itself doesn't do anything useful (draws some shapes in the main window, purely as an indication that the buttons etc are doing what they are meant to. Controls jump around in the dialogue box in an alarming and very annoying way - of course one would never actually do this, but it is just to test out the functions.
In some cases I have provided a proc/function as a very thin wrapper (for example, PROCsetdlgtext) - in that case because it is a logical pair to FNgetdlgtext (which is stolen straight from the manual). In others, such as GetWindowRect, I haven't bothered, which may be inconsistent - one could of course easily add these.
I'd be interested to know if anyone else thinks this kind of thing would be useful.
Best wishes,
David
|
|
Logged
|
|
|
|
|
