Author |
Topic: The future of BBC BASIC for Windows (Read 251 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
Re: The future of BBC BASIC for Windows
« Reply #8 on: Mar 4th, 2012, 11:23am » |
|
on Mar 3rd, 2012, 10:26pm, David Williams wrote:| These Example Programs, published in HTML form, in a nice visually-pleasing, high-clarity font, should convey ease-of-use and accessibilty in as friendlier way as possible. |
|
I can't help thinking that, however much effort you put into making them attractive etc., they are no real substitute for being able to experiment yourself with programs that actually run in the trial version. After all it's hardly a trial version if it doesn't let you try things!
Quote:Release TWO Trial versions of BB4W, thereby giving prospective customers users the choice |
|
I must say that really doesn't appeal to me at all. Would you have two different shortcuts on the desktop, or would it initially prompt for which 'limitation' you wanted (memory or time) for that particular session? People would always be trying to 'beat the system' by using the memory-limited option to edit their programs and the time-limited option to test them! Can you imagine constantly switching between the two to optimise your use of the 'free' time? Yuk!
How about attempting a technical solution, such as providing a special 'wrapper' version of GUILIB which contains only the function and procedure entry points (and therefore fits in the trial version's limited memory) and then somehow calls the 'real' library, which is resident in some API-allocated memory block? This would be a bit like the API hack for making large arrays accessible to the trial version, but for PROCs and FNs.
I've not given this any detailed thought, but it's not a million miles away from what CLASSLIB does already to implement Object Classes.
Richard.
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #9 on: Mar 4th, 2012, 3:44pm » |
|
on Mar 4th, 2012, 11:23am, Richard Russell wrote:| I've not given this any detailed thought, but it's not a million miles away from what CLASSLIB does already to implement Object Classes. |
|
OK, here's a proof of concept. The GDI+ library GDIPLIB is too large to load in the trial version, with the default setting of HIMEM. I have put a wrapper library GDIPLIB_ (using a simple adaptation of the code in CLASSLIB) here; download it to your @lib$ folder:
http://tech.groups.yahoo.com/group/bb4w/files/Libraries/GDIPLIB_.BBC
You should now find that the GDI+ demo program below runs successfully in the trial version:
Code: REM. Demonstration of GDI+ library
LineEndSquare = 1
LineEndRound = 2
LineEndTriangle = 3
LineEndSquareAnchor = &11
LineEndRoundAnchor = &12
LineEndDiamond = &13
LineEndArrow = &14
LineStartSquare = &100
LineStartRound = &200
LineStartTriangle = &300
LineStartSquareAnchor = &1100
LineStartRoundAnchor = &1200
LineStartDiamond = &1300
LineStartArrow = &1400
LineDash = &10000
LineDot = &20000
LineDashDot = &30000
LineDashDotDot = &40000
INSTALL @lib$+"GDIPLIB_"
VDU 23,22,640;480;8,16,16,128
PROC_gdipinit
REM Near-horizontal line to demonstrate antialiasing
pencolour% = &FFFF0000 : REM. Opaque red
penstyle% = LineStartArrow + LineEndArrow
penwidth = 4.0
pen% = FN_gdipcreatepen(pencolour%, penstyle%, penwidth)
PROC_gdipline(pen%, 0, 200, 1280, 210)
PROC_gdipdeletepen(pen%)
REM Near vertical line to demonstrate antialiasing
pencolour% = &FF008000 : REM. Opaque dark green
penstyle% = LineDashDot
penwidth = 2.0
pen% = FN_gdipcreatepen(pencolour%, penstyle%, penwidth)
PROC_gdipline(pen%, 200, 0, 210, 960)
PROC_gdipdeletepen(pen%)
REM Bezier curve from four control points
pencolour% = &FF0000FF : REM. Opaque blue
penstyle% = LineStartRound + LineEndArrow
penwidth = 5.0
pen% = FN_gdipcreatepen(pencolour%, penstyle%, penwidth)
PROC_gdipbezier(pen%, 20, 20, 200, 200, 400, 600, 800, 600)
PROC_gdipdeletepen(pen%)
REM Ellipse made from 360-degree arc
pencolour% = &A0FF8000 : REM. Translucent orange
penstyle% = 0
penwidth = 3.0
pen% = FN_gdipcreatepen(pencolour%, penstyle%, penwidth)
PROC_gdiparc(pen%, 500, 500, 150, 100, 0, 360)
LINE 500, 500, 500, 500
PROC_gdipdeletepen(pen%)
REM Filled sector, 3/4 of an ellipse
brushcolour% = &FFFF00FF : REM. Opaque magenta
brush% = FN_gdipcreatebrush(brushcolour%)
PROC_gdipsector(brush%, 900, 800, 100, 150, 90, 270)
LINE 900, 800, 900, 800
PROC_gdipdeletebrush(brush%)
REM Filled five-pointed star
brushcolour% = &FF808080 : REM. Opaque grey
brush% = FN_gdipcreatebrush(brushcolour%)
DIM X(4), Y(4)
X() = 1100,900,1060,1000,940
Y() = 430,430,320,500,320
PROC_gdippolygon(brush%, 5, X(), Y(), 0)
*GSAVE alternate 900,320,200,180
PROC_gdippolygon(brush%, 5, X(), Y(), 1)
*GSAVE winding 900,320,200,180
PROC_gdipdeletebrush(brush%)
REM Square drawn with polyline
pencolour% = &FF000000 : REM. Opaque black
penstyle% = 0
penwidth = 2.0
pen% = FN_gdipcreatepen(pencolour%, penstyle%, penwidth)
DIM xx(4), yy(4)
xx() = 500,500,600,600,500
yy() = 700,800,800,700,700
PROC_gdippolyline(pen%, 5, xx(), yy())
PROC_gdipdeletepen(pen%)
REM Angled ellipse drawn with polybezier
pencolour% = &FF00FF00 : REM. Opaque bright greenn
penstyle% = 0
penwidth = 2.0
pen% = FN_gdipcreatepen(pencolour%, penstyle%, penwidth)
PROCgdipellipse(pen%, 350, 800, 50, 100, PI/4)
PROC_gdipdeletepen(pen%)
PROC_gdipexit
END
DEF PROCgdipellipse(pen%, x, y, a, b, t)
LOCAL c, d, o, p, q, r, x(), y()
DIM x(12), y(12)
c=a*SIN(t) : a=a*COS(t)
d=b*SIN(t) : b=b*COS(t)
o=a*0.552285 : q=c*0.552285
p=b*0.552285 : r=d*0.552285
x() = x-a,x-a-r,x-o-d,x-d,x+o-d,x+a-r,x+a,x+a+r,x+o+d,x+d,x-o+d,x-a+r,x-a
y() = y+c,y-p+c,y-b+q,y-b,y-b-q,y-p-c,y-c,y+p-c,y+b-q,y+b,y+b+q,y+p+c,y+c
PROC_gdippolybezier(pen%, 13, x(), y())
ENDPROC
Obviously this technique could be abused to work around the limitations of the trial version, but as with the array hack if somebody is prepared to go to that amount of trouble they probably deserve to succeed!
If you haven't already got both full and trial versions installed (as 'power' users I would think it likely you have!) see the instructions here:
http://bb4w.wikispaces.com/Installing+both+demo+and+full+versions
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender: 
Posts: 248
|
|
Re: The future of BBC BASIC for Windows
« Reply #10 on: Mar 4th, 2012, 10:57pm » |
|
Wow! Very good!
I notice you used a fail safe so that it can be used with every library. In the case of GDILIB you need to call the init first so in reality the GDILIB_ Wrapper could contain only:
Code:
REM Wrapper for GDIPLIB
DEF FN_gdipcreatepen(C%, S%, w)
DEF FN_gdipcreatebrush(C%)
DEF PROC_gdipdeletepen(P%)
DEF PROC_gdipdeletebrush(B%)
DEF PROC_gdipline(P%, x1, y1, x2, y2)
DEF PROC_gdippolyline(P%, N%, x(), y())
DEF PROC_gdipbezier(P%, x1, y1, x2, y2, x3, y3, x4, y4)
DEF PROC_gdippolybezier(P%, N%, x(), y())
DEF PROC_gdiparc(P%, xc, yc, xr, yr, as, ad)
DEF PROC_gdipsector(B%, xc, yc, xr, yr, as, ad)
DEF PROC_gdippolygon(B%, N%, x(), y(), M%)
DEF FN_gdipg
DEF PROC_gdipinit : PROC_gdip_redirect : PROC_gdipinit : ENDPROC
DEF PROC_gdipexit
DEF PROC_bbc2api(RETURN x, RETURN y)
DEF FN_f4(A#)
etc...
or
Code:
REM Wrapper for GDIPLIB
DEF FN_gdipcreatepen(C%, S%, w)
DEF FN_gdipcreatebrush(C%)
DEF PROC_gdipdeletepen(P%)
DEF PROC_gdipdeletebrush(B%)
DEF PROC_gdipline(P%, x1, y1, x2, y2)
DEF PROC_gdippolyline(P%, N%, x(), y())
DEF PROC_gdipbezier(P%, x1, y1, x2, y2, x3, y3, x4, y4)
DEF PROC_gdippolybezier(P%, N%, x(), y())
DEF PROC_gdiparc(P%, xc, yc, xr, yr, as, ad)
DEF PROC_gdipsector(B%, xc, yc, xr, yr, as, ad)
DEF PROC_gdippolygon(B%, N%, x(), y(), M%)
DEF FN_gdipg
DEF PROC_gdipinit : PROC_gdip_redirect : PROC_gdipinit
DEF PROC_gdipexit
DEF PROC_bbc2api(RETURN x, RETURN y)
DEF FN_f4(A#)
ENDPROC
Although I understand that many libraries do not have an init PROC and so you would have to ensure that you do what you did.
All in all though, great. Definitely the way to make a large library available without having to change anything in the trial version.
I particularly like the !EVAL() which is also so essential in CLASSLIB.
Quote:| Each function should be documented fully. |
|
Now the full library could be as verbose as you like.
Michael
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #11 on: Mar 9th, 2012, 1:38pm » |
|
So, from the general lack of response, I suppose I must conclude that hardly anybody else shares my concern that BBC BASIC is significantly inferior to Liberty BASIC in some important respects. This is disappointing, but not altogether unexpected.
On that basis I have to assume there is little enthusiasm for a new GUILIB library. It is my opinion that without such a library BBC BASIC should not be promoted as a 'Windows' programming language, since it does not adequately support the GUI paradigm that is the essence of Windows.
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: The future of BBC BASIC for Windows
« Reply #12 on: Mar 9th, 2012, 5:28pm » |
|
on Mar 9th, 2012, 1:38pm, Richard Russell wrote:| .... shares my concern that BBC BASIC is significantly inferior to Liberty BASIC in some important respects. |
|
I am sorry, I am just not able to comment not being a LB user.
I am willing to help get a GUILIB up and running. But with this I would not be able to compare it to LB at all.
I don't know who else in the world of BB4W also uses LB except for Gordon and you, and the few posters in the yahoo groups.
Michael
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #13 on: Mar 9th, 2012, 10:01pm » |
|
on Mar 9th, 2012, 5:28pm, Michael Hutton wrote:| I am sorry, I am just not able to comment not being a LB user. |
|
Although one could use the LB GUI model as a template for the sort of features a new GUILIB should provide, an equally valid template might be the Visual Basic model, or any other GUI framework. I would welcome suggestions from all sources.
What is clear is that the existing WINLIBx libraries aren't satisfactory. They were some of the earliest BB4W libraries ever written, at a time when my understanding of the Windows GUI was poor and my experience with other GUI frameworks was zero! If BB4W is to be competitive it needs an entirely new approach to supporting the Windows GUI.
One thing that worries me, though, is that several people in this group (and the wider BB4W user community) probably have no experience of any other GUI framework. They therefore cannot see just how awful the existing WINLIBx libraries are, because they are all they have ever known! This is a recipe for disaster.
Perhaps I could ask everybody reading this (yes, that means you) to give a brief resume of their experiences with other Windows GUI frameworks and what they can bring to the party if we are to get this GUILIB idea off the ground.
Richard.
|
|
Logged
|
|
|
|
Andy Parkes
Developer
member is offline
Gender:
Posts: 25
|
|
Re: The future of BBC BASIC for Windows
« Reply #14 on: Mar 12th, 2012, 11:37am » |
|
Hi All,
As I was reading through the messages thus far, I began by thinking that the WINLIBx libraries were adequate for their respective purposes. But even so, over the years I have written several simple functions and procedures to facilitate my use of these libraries, typically things that just take the monotony out of enabling dialogue controls etc.
I am sorry to say that I have no experience of other Windows GUI frameworks, and I had assumed that WINLIBx was about as easy as it got. However, I have long since noticed the limitations of WINLIBx. As Richard said, at the beginning, difficulty increases a lot, with user interface complexity. You guys - and some other folks - have written very helpful articles in the BB4W Wiki. Although I have been able to make good use of this, and increase my repertoire, there is a lot of useful work in both in the Wiki and the reference manual, which could be put at people’s fingertips by structuring it in a library. I think a 'List View' control is but one example of something crying out for library support.
I agree with Richard’s suggestion that the limitations of the library interface to the GUI, is one of the weaker aspects of BB4W. GUI programming does matter. I think most programmers get their kicks out of seeing what other people can do with their programs. Most people use Windows, most people want the Windows GUI.
I take Richards point that I (we) may be slightly delusional about the relative value of WINLIBx. Let’s first take GUILIB as far as we can, then see how we feel about WINLIBx.
The trial version of BB4W without the time limit is most helpful, and makes it easy for someone to use BB4W as a platform for teaching programming.
It is difficult for me to say at this point just how I might be of service. I'm certainly not going to be pushing the frontiers of this, but I can probably reconstitute things that are already within the scope of the Wiki and manual, into the given library format. I’m still (slooowly!) learning assembly language, so I won’t be doing anything technical!
If I was doing something like this myself, I would start with a list of what I would like to include (with descriptions for each item, stating how I would like to see it implemented – that is to say, primarily a description of how it should look from the point of view of someone using the library).
This idea is rather jumping the gun, but if it is the case that GUILIB ends ups comprising hundreds of functions and procedures, it might be nice to have a tool, which weeds out the hundred or so which are not actually used by a particular program. A good example of this is DrWIMP , another BASIC library that is similar in concept to that which we are now proposing. DrWIMP is a 'GUILIB' for use with RISC OS BASIC V. RISC OS does not offer the variety that Windows does, yet even this single library contains approximately 292 functions and procedures. It gets past the drag factor with a linker.
I have not given this much thought yet, but DrWIMP is perhaps a good example of a library that makes event driven programming feel ‘natural’ in an intrinsically procedural programming language. The library is supplied with a skeleton application. The skeleton application contains predefined functions, which are called by the library depending upon the event which needs handling. I can’t remember the correct names of the functions, but as you would expect there is something along the lines of, FNuser_mouseClicked, FNuser_mouseRollOver, FNuser_mouseEnterWindow, FNuser_mouseLeaveWindow, FNuser_windowMoved, FNuser_windowResized etc. Then all the programmer has to do is fill each function with code to filter the window handle, button handle, mouse button used (all passed to each function) etc., and generate the appropriate response. The values returned from these functions provide a way of optionally returning values to the DrWIMP library depending upon the outcome of the filtered mouse click etc.
It’s been a while since I last used it, but I do recall DrWIMP being very easy to use, and also that it was a significant enabler under RISC OS, partly because BASIC V does not have something equivalent to ON SYS etc., also the RISC OS API seems to me now, to be more difficult than the Windows API, but that might just be the effect of time.
It’s probably worth mentioning that I'm ISP challenged (connection today is courtesy of my very noisy local library). I can't say when I'll be back, but I will be! In the mean time, I'm going to download and install the trial version of LBB to see if there is anything I can glean.
Regards
Andy Parkes
|
|
Logged
|
|
|
|
DDRM
Administrator
member is offline
Gender:
Posts: 321
|
|
Re: The future of BBC BASIC for Windows
« Reply #15 on: Mar 13th, 2012, 09:54am » |
|
Hi Richard,
Sorry for the delay in responding, but it’s been rather a busy time. I AM interested, and I DO think there is potential for improvement.
One comment before I start on the main response. I suspect you tend to see BB4W as a way of producing high-class applications for the Windows environment, and so it is. Making that easier is highly desirable, and will undoubtedly increase its appeal. However, I suspect that many, perhaps most, users are beginners or relatively low level hobbyists, for whom the simplicity and immediacy of the language is very appealing. The ability to give one or two parameters, do some calculations, and then plot a simple graph, all in the main window, and all in a handful of lines of code, is very rewarding. I would be very sad if we lost that simple, basic, underlying approach in moving more towards a GUI-oriented approach, where one has to faff about getting the interface sorted before you can do anything with it!
In response to your original question on this strand, I agree that BB4W can do virtually everything I would want to do in the context of Windows programming, but that the library support for API commands could be better, and make life easier. Even more detailed Help would help - for example, the Help for many of the libraries gives examples of the style codes to do obviously helpful things, but not the full list. I appreciate adding ALL options in each place isn’t practical, but it does mean often going away and having to find (somewhere else) what those options, and either the values or the variable names, are.
Most of my programming experience is in various dialects of BASIC, going back into the 80s, though I was also competent (in my own, rather limited terms) in Turbo Pascal. In terms of languages that used the Windows interface, I have really only used Visual Basic and BB4W. Probably because of my background, I HATED VB, because it was SO focussed on event-driven programming, and a lot of the time I was interested in programs which would be doing a lot in the background, and then showing me the results - for me, then, finding BB4W was a blessing and a great relief. Having said that, the VB way of doing things - design the interface elements, and then put code in to make them all work - works very well for that kind of application.
One thing that I particularly liked in VB was that one could set or read parameters of a control directly - so, for example (and forgive me if the syntax is not exactly correct - I don’t have VB on this computer, and have barely used it since discovering BB4W) to set or read the contents of an edit control on simply wrote
editbox1.text=”Hello world!”
Indeed, one can use them as variables in an expression. This is much more user friendly (to my mind) than having to use
SYS "SetDlgItemText", !dlg%, id%, text$.
My guess is that this would be difficult to implement directly in BB4W, and is what you mean when you say that LB is different because it makes the GUI components an intrinsic part of the language (or something like that - can’t find the reference to hand). I wonder though whether it would be possible to handle this via a level of abstraction. I haven’t thought through how this would have to work, but could you have a structure associated with each control, containing its key (user settable/readable) characteristics, and then hide all the systems calls in the background, via a library? That might mean
PROCGUI_Write(editbox1.text,”Hello world!”) , or boxcontents$=FNGUI_Read(editbox1.text$),
for example. Then each time you create a new control, an associated structure would be made, containing default parameters (perhaps filled via DlgEdit or an equivalent).
Would it be possible and useful to provide a similar abstraction for MODE, PLOT and some of the VDU codes? For example, to be able to
PROCGraphics_SetMainWindow(xres%,yres%,bigchars%,colours%)
PROCGraphics_Trianglefill(x1%,y1%,x2%,y2%,x3%,y3%,colour%).
Best wishes,
David
|
| « Last Edit: Mar 13th, 2012, 09:56am by DDRM » |
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #16 on: Mar 13th, 2012, 11:51am » |
|
on Mar 13th, 2012, 09:54am, DDRM wrote:| The ability to give one or two parameters, do some calculations, and then plot a simple graph, all in the main window, and all in a handful of lines of code, is very rewarding. I would be very sad if we lost that simple, basic, underlying approach |
|
I can't see that there's any prospect of 'losing' that ability (after all I'm not proposing any changes to BB4W itself!). As the likes of Jonathan Harston emphasise, graphics are not actually 'part' of BBC BASIC anyway: they are an OS feature which is emulated in BB4W to improve compatibility with the BBC Micro and Acorn Archimedes.
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #17 on: Mar 13th, 2012, 12:02pm » |
|
on Mar 13th, 2012, 09:54am, DDRM wrote:| Then each time you create a new control, an associated structure would be made |
|
You seem to be talking about Object Oriented programming here. I have wondered to what extent a possible GUILIB could/should be integrated with CLASSLIB, but I can see potential for an adverse reaction from users if they are forced to learn and use the (somewhat kludgey) OO syntax that CLASSLIB requires. Bear in mind that CLASSLIB (as recently improved by Jon Ripley) represents the 'state of the art' as far as a BB4W OO library is concerned; I don't think it's possible to do much better without modifying the language.
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #18 on: Mar 13th, 2012, 5:46pm » |
|
on Mar 13th, 2012, 09:54am, DDRM wrote:to set or read the contents of an edit control on simply wrote
Code:editbox1.text=”Hello world!” |
|
That's similar to the Liberty BASIC syntax:
Code:#window.editbox1 ”Hello world!”
but of course BBC BASIC has nothing similar, and modifications to the language are not on the agenda.
Options one would have in BBC BASIC include:
The current way:
Code:SYS "SetWindowText", hctrl%, text$
A minimal thin wrapper (basically just a cheat to make it look more native):
Code:PROC_SetText(hctrl%, text$)
A more hierarchical approach:
Code:PROC_SetText(hdlg%, idctrl%, text$)
Using a structure-like syntax (but I'm not sure this is practical, because BB4W doesn't support creating a structure dynamically):
Code:PROC_SetText(dlg.ctrl, text$)
The Object Oriented approach e.g. using CLASSLIB:
Code:PROC(ctrl.SetText)(text$)
Do any of these particularly appeal? If not, have you any suggestions for an alternative?
Richard.
|
|
Logged
|
|
|
|
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
|
|
|
|
|
