Author |
Topic: The future of BBC BASIC for Windows (Read 236 times) |
|
admin
Administrator
member is offline
Posts: 1145
|
 |
The future of BBC BASIC for Windows
« Thread started on: Feb 29th, 2012, 5:26pm » |
|
Long message, sorry.
Let me kick off this discussion with some background, so you all know where I am coming from. A few years ago I announced that BB4W was transitioning from a status of 'active development' to that of 'maintenance', in other words new releases would be for the purpose of bug-fixes and other minor tweaks only, rather than major additions to functionality.
There were a number of reasons for that decision, but primarily it was a risk/benefit judgement based on a gut feeling that the benefits of any major additions could be more than offset by the risks of introducing bugs. One of the key characterisitics of BB4W, IMHO, is its stability and freedom from bugs and I didn't want to damage that.
Nevertheless, it wasn't a decision taken lightly. I wanted to reassure myself that there were no serious shortcomings in BB4W that could cause users (or me) annoyance if they were not addressed. I decided that a good way of assessing the 'completeness' of BB4W would be to attempt to emulate another major interpreted BASIC - QBASIC. QBASIC is a little younger than BBC BASIC but is similar in respect of the facilities it provides; if BB4W could emulate QBASIC fairly comprehensively then there ought not to be any serious weaknesses.
So it was that I developed QB2BBC, the QBASIC to BBC BASIC translator. I realised from the outset that two fairly major enhancements to BB4W would be needed: support for labels and the EXIT keyword; neither of those features could have been emulated in an acceptable way otherwise. They were added in BB4W version 5.60a (May 2007), although the support for labels was initially kept 'secret' for fear of the reaction from die-hard BBC BASIC enthusiasts who consider labels the invention of the Devil! Thus the value of QB2BBC in identifying shortcomings in BBC BASIC was proven.
Fast forwarding four years, I decided in 2011 to write a Liberty BASIC to BBC BASIC translator. Since Liberty BASIC is a more modern dialect (originating in the early 1990s) it might prove an even better test of the 'completeness' of BB4W. I was pleasantly surprised at how few tweaks to BB4W proved to be necessary to emulate LB fairly comprehensively: a change to the way strings are passed to SYS and a couple of file-reading enhancements: GET$# TO and GET$# BY, which were implemented in BB4W v5.93a (needless to say I didn't own up at the time that they had been added specifically to support LBB!).
There are a couple of features of Liberty BASIC that BBC BASIC cannot emulate: huge strings (up to 16 Mbytes or more) and arbitrary-precision integers. Supporting either of those would have been far too challenging, and they remain the most significant compatibility issues as far as LBB is concerned. Nevertheless, writing QB2BBC and LBB has convinced me that BBC BASIC for Windows has no serious shortcomings, and that there is no reason to re-visit my decision to discontinue active development.
Therefore, and most importantly, I do not consider modifications to BB4W to be on the agenda. If I release any further updates, and that isn't certain, they will be only to address bugs (such as the one identified yesterday - grrr!) and to provide the opportunity to update example programs and libraries.
And that brings me to what I really want to discuss (sorry it's taken so long to get to the point): how adequate are the existing libraries supplied with BB4W? Because BBC BASIC, as a dialect, pre-dates the Graphical User Interface concepts that are so important these days, GUI support necessarily requires the use of libraries (principally the WINLIBx libraries). They are supposed to make accessing the Windows API fairly straightforward, but from the earliest days of BB4W it has been apparent that many users find using those libraries far from easy.
I have also, over the years, received a number of comments from those few users of both BBC BASIC and Liberty BASIC (hello Gordon!) to the effect that LB makes it much easier to use GUI features in a program than BB4W does. My initial reaction to such comments (from the perspective of a non-LB user) was to demonstrate that I could produce the same functionality in BB4W. But that missed the point: I could do it, as a very experienced BBC BASIC user, but a lot of people couldn't!
I needed a new perspective on this issue, and that was another reason for taking a more serious interest in Liberty BASIC. Inevitably, in writing the translator from LB to BB4W, I have acquired a far better understanding of LB than I had previously. This has demonstrated two points to me very clearly:
In terms of GUI capability, BB4W is fine: it can do everything that LB can.
In terms of ease of use of GUI support, BB4W (with the existing libraries) is far inferior to LB. The way I now look at this is in terms of a graph of difficulty versus UI complexity. For the simplest kinds of user interface (the sort of thing one would have done on the BBC Micro) BBC BASIC is extremely easy to use (easier than LB). This isn't surprising given its background in the 1980s: it is richly provided with native text and graphics features. But as one moves towards more complex and 'modern' GUI features (windows, controls, buttons, sprites etc.) the difficulty curve soon overtakes LB. For many features (such as advanced use of sprites, or multiple windows) BB4W effectively lacks any native or library support at all. At this level, resorting to assembler code and direct calls to the Windows API is the only way.
One of the things I would like to trigger a discussion on is: does this matter? Perhaps there is no need to 'compete' with LB. Perhaps it's fine for somebody who wants to use GUI features in his program to migrate to LB rather than using BB4W. On the other hand one might argue that it is letting BB4W users down not to provide GUI libraries which can match the sort of thing it's easy to do in LB.
So what do you think? Do you agree with me that the main weakness of BB4W is not the native language but the libraries? Do you care that it's much easier to implement certain GUI features in Liberty BASIC than in BBC BASIC? What, if anything, should be done about this?
Richard.
|
| « Last Edit: Feb 29th, 2012, 9:55pm by admin » |
 Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender: 
Posts: 452
|
|
Re: The future of BBC BASIC for Windows
« Reply #1 on: Feb 29th, 2012, 9:16pm » |
|
I'll need a few days to digest and reflect before I can comment, although I might, in the end, prefer not to (comment).
I am definitely interested in reading others' opinions on the points raised in this thread's opening post.
Now, back to finalizing version 2.03 of my little library...
David.
|
|
|
|
kcpsm
Developer
member is offline
Posts: 2
|
|
Re: The future of BBC BASIC for Windows
« Reply #2 on: Mar 1st, 2012, 10:16am » |
|
Dear Richard,
So a long message in return!
I’m not sure if this will help your thinking or not but I’m delighted to have the opportunity to provide at least some feedback and inputs to you since BB4W has absolutely saved my bacon and made my work so much easier since I bought my first copy in May 2010.
What do people need?
It should go without saying that whatever BB4W (or absolutely anything if you think about it) is, it has to work correctly. Richard, please do not underestimate how much I, and presumably everyone else, values the fact that BB4W does work so well. Hence, I will stand behind you 100% and agree that it is better to maintain the high standard that you have achieved rather than to add new features with the potential to inject bugs (or at least strange effects). With operating systems continuous changing I think you have more than enough on your plate!
Anyway, beyond that, I’m going to narrow this down to just two use models....
a) Compatible with old code.
This is really tricky to pull off completely. When people say they want something to be “the same” then they often don’t really mean that. Running the same code today that used to be run on a 1MHz 8-bit processor with a 40x25 character display can be useful but the chances are it will run way too fast on a PC and the display will be interesting to say the least. Nice form a historical perspective but if the code has further value then it will almost certainly start to be changed to make it suitable for the modern world and machines. So quite how compatible it needs to be is debatable.
I was previously using QuickBASIC for DOS (v4.5). This had the fundamental limit of 64KB of memory so if I have looked for something 100% compatible then it would also have had a memory limit or would have had to interpret the memory manipulation tricks that I needed to use which is ugly as well as pointless.
However, what attracted me to BB4W was that it was ‘compatible with me’. I was (and still am) a SHARP MZ80A owner with Sharps’ own BASIC and Pascal to use in my play and studies. So I’m not from the BBC Micro stream and had never used BBC BASIC before. But what I really saw in BB4W was the true essence of the BASIC language, and just as importantly, that simple working environment where I could just start writing a program and run it. No need to be a computer whiz setting up options and defining windows and memory allocations etc. To cap it all, it just spits out a single EXE file that I can give to anyone and it doesn’t need to be installed with a load of drivers etc.
My field of work is actually hardware design and hardware languages such as VHDL. Whatever anyone claims, there is no such thing as compatible code there either. Even clamped down by rigorous standards of the language itself, for all kind of good and bad reasons people end up with special attributes and directives in their code to make something work with ‘A’ but not with ‘B’. My point being that people say they use a language because it is compatible, portable and timeless etc but in realistic it nearly always needs to be tweaked to fit the final application.
My suggestion – May be if BB4W encountered a keyword from a variant of BASIC that is not supported it could simply present an error message that contained information leading the user to the appropriate equivalent. You already provide so much useful and well written help and information, we just need a pointer to the right place sometimes.
b) To create something absolutely new.
So if someone if going to create something entirely new then compatibility with anything else really shouldn’t be important. Let’s not confuse ‘compatibility’ with being ‘nicely familiar’ so I can make rapid progress.
In my case I did find myself effectively re-writing applications that I had implemented in QuickBASIC in the past but I very quickly got used to any syntax differences. I suppose it would have been nice to just cut and paste in big lumps of old QB code but in reality so much of the code was styled to cope with limitations that were completely gone in BB4W (namely, memory was no longer an issue).
Just about everything I do is based on simple text I/O or communication with a COM port. It always takes a while to learn and convince yourself that you can do these things and once you have a recipe for each the rest is pure fun.
The point I’m trying to make is that once you are writing all new code then you soon get comfortable with the ‘coat you are wearing’ and it becomes the standard against which you measure all others. That is reinforced by the very fact that BB4W works so well and is so easy to ‘wear’. What scares me is what on earth I will do if the next incarnation of Windows comes out and BB4W doesn’t work with it. You see, it is far more important for me to have what we have today in the future rather than adding anything else.
I soon got into BB4W and for the most part made rapid progress because most of my code is similar. Then every now and again I need to do something a bit different and new to me. Call me sad if you like, but this is where the gold old fashioned fun of learning how to do something kicks in. Initially I think something can’t be done but so far there has always been a way with BB4W (even if I had to ask you directly for a clue). There really shouldn’t be a need to add anything to BB4W unless there is absolutely no way of achieving it in a reasonable way. Even then, it should be something that at least more than one person would ever need.
As to ‘Libraries’ then I’m going to admit that I have never used any of them at all! I’m sure there is lots of wonderful stuff in them but I have a personal preference for keeping everything as ‘primitive’ as I possibly can. I guess I’ve just had bad experiences in software and hardware in my past. Anyway, on that basis I won’t comment on libraries as I’m not qualified to do so but I do again want to emphasize how my use model of BB4W is really fundamental and it is that which it services so well.
I hope some of my rambling is of help.
Regards,
Ken
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #3 on: Mar 1st, 2012, 11:02am » |
|
on Mar 1st, 2012, 10:16am, kcpsm wrote:| As to ‘Libraries’ then I’m going to admit that I have never used any of them at all! I’m sure there is lots of wonderful stuff in them but I have a personal preference for keeping everything as ‘primitive’ as I possibly can. |
|
I may not be typical, but I almost always want my programs written in BB4W to have the 'look and feel' of a conventional Windows application. To me, the essence of Windows is the standardisation of the User Interface between applications, so that you don't have to learn a new way of selecting files, or a new way of choosing a command from a menu, for every new program you use. I want a user of one of my applications to immediately feel 'at home'. If he happens to prefer a different Windows 'theme', or is disabled and requires 'accessibility' features to be enabled, they should work in the way he is familiar with.
That unavoidably means using the Windows API, since writing your own GUI 'clone' with all the subtleties of keyboard shortcuts, user configuration, accessibility options etc. would be impossible and pointless. Doing it all with SYS calls and assembler code would be well beyond the capabilities of most users, so that's where the libraries come in.
It actually concerns me quite a lot if BB4W encourages people not to use the standard Windows GUI for their programs. I don't want to be reponsible for loads of programs with non-standard User Interfaces coming onto the market!
One of the nice things about Liberty BASIC is that it strongly encourages you to write programs with the Windows look-and-feel. It does provide a crude 'glass teletype' style of interface, but that doesn't support graphics or colours. To do anything at all 'attractive' requires a committment to the Windows GUI. I think that is a very good thing.
So although I can't force anybody to adopt a standardised User Interface, I would like it to be as straightforward as it is in LB so they have no excuse not to, other than being perverse. At the moment that's not the case.
Richard.
|
|
Logged
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: The future of BBC BASIC for Windows
« Reply #4 on: Mar 3rd, 2012, 7:05pm » |
|
"how adequate are the existing libraries supplied with BB4W?"
This is going to be very brief as I have to rush off (not ideal):
1. Keep the old WINLIBX libraries.
2. Make one new large library GUILIB or something similar with all functions needed to make/manipulate windows GUI tools. This may prevent the eternal confusion as to which library I need (WINLIB2 boxes and buttons or is it WINLIB3A or is there a WINLIB4C now.... oh gosh... etc....)
3. Maintain a strict English naming convention for ease of look up for the function names eg
DEF FN_GUILIB_ButtonOnHWND()
DEF FN_GUILIB_ButtonInDialog()
DEF FN_GUILIB_ProgressBarAdvance()
DEF FN_GUILIB_ProgressBarClear()
DEF FN_GUILIB_CreateDialog()
etc etc
or something similar, I personally like Camel Notation. Length of names does not matter.
This make it easier for everyone to contribute functions.
4. Make them all FUNCTIONS so we can see return values.
5. Make a repository where we can all submit functions to add and others can see and edit/correct before they are added to a version.
6. Each function should be documented fully.
7. Only use statics for local variables etc...
6. I have to go but I'll be back!
Michael
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: The future of BBC BASIC for Windows
« Reply #5 on: Mar 3rd, 2012, 9:29pm » |
|
on Mar 3rd, 2012, 7:05pm, Michael Hutton wrote:| Make one new large library GUILIB |
|
I'm attracted to that idea in principle, but it would almost certainly be too big for the trial version of BB4W. We could then end up with a situation where somebody evaluating BB4W to see if it suits his needs isn't able to use the very library that may persuade him of its suitability!
I would be loathe to move to the LB model of having a trial version with unrestricted memory but time-limited. Any thoughts on this issue?
Quote:| Make them all FUNCTIONS so we can see return values |
|
I can't see the point of making something a function, if it inherently doesn't have a value to return. Isn't it more natural for those which do return a value to be functions and those which don't procedures? Looking at LB for inspiration, hardly any of its GUI operations are functions.
Quote:| Each function should be documented fully. |
|
Presumably not within the library itself, otherwise the size issue becomes even more important.
One could conceivably adopt the technique that I have with LBLIB of supplying a crunched version of the library, which is what you actually INSTALL. That's a neat solution, but it imposes quite serious constraints on how the code is written (I get away with it for LBLIB only because the main BASIC program is created automatically, so I know exactly what variables it uses etc.).
Quote:| Only use statics for local variables etc... |
|
Statics? Are you in fact proposing that this library be written in C (i.e. a DLL)? That would certainly solve the 'trial version' issue but it's a drastic step! 
If it was written in BASIC, as I had anticipated, I would want to avoid PRIVATEs (if that's what you meant) as much as possible because of their adverse interaction with ON ERROR.
Richard.
|
|
Logged
|
|
|
|
David Williams
Developer
member is offline
meh
Gender:
Posts: 452
|
|
Re: The future of BBC BASIC for Windows
« Reply #6 on: Mar 3rd, 2012, 10:26pm » |
|
on Mar 3rd, 2012, 9:29pm, Richard Russell wrote:I'm attracted to that idea in principle, but it would almost certainly be too big for the trial version of BB4W. We could then end up with a situation where somebody evaluating BB4W to see if it suits his needs isn't able to use the very library that may persuade him of its suitability!
I would be loathe to move to the LB model of having a trial version with unrestricted memory but time-limited. Any thoughts on this issue? |
|
Whilst not myself into GUI programming, I like Michael's idea. What a pity if it doesn't gain wings just because it won't be able to work with the trial version of BB4W due to the limited memory available.
Two ideas:
(1) Write the single, big GUI library, and keep the existing memory-limited BB4W Trial Version model, but write (not single-handedly!) dozens of crystal-clear, well-commented Example Programs showing HOW EASY it is to use BB4W + GUILIB to make GUI-based programs, and publish the programs in HTML form for immediate browsing -- BB4W not required, and for each program, provide a link to a compiled EXE so that the prospective BB4W user can see the program in action. The first dozen-or-so example programs should be very short, and sweet. Then they get progressively longer, complex and more interesting in what they do. 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.
Idea #2: Release TWO Trial versions of BB4W, thereby giving prospective customers users the choice between:
A) The usual memory-limited version
B) Significantly more memory (not necessarily as much as 256 MB!), but time-limited. I remember loathing LB's "Nag Screen", and having to wait minutes before being able to use the program, but you don't have to go there. Just do as many other trial-version software packages do: Give the user a total of a few hours (over multiple sessions), and eventually the eggtimer runs out with something like the resulting message: "Thank you for trying BBC BASIC for Windows, but I'm afraid your three-hour Trial Period is now up! If you'd like to purchase..." (or whatever).
Possibly combine Idea #1 with Idea #2, option B: Lots of nice, simple Example Programs in .BBC and HTML form (published and readily browsable on a website), and a time-limited, less memory-constrained, no-nag-screen Trial Version of BB4W.
(And, it goes without saying, that with the alternative Trial Version of BB4W, prospective users can use or try -- ahum -- my library as well).
Michael: Have you changed your e-mail address recently? I tried sending you an e-mail the other day and it bounced!
David.
|
|
|
|
Michael Hutton
Developer
member is offline
Gender:
Posts: 248
|
|
Re: The future of BBC BASIC for Windows
« Reply #7 on: Mar 4th, 2012, 09:48am » |
|
"but it would almost certainly be too big for the trial version of BB4W"
I hadn't thought about that. I suppose there is a potential of GUILIB could become rather a monster. I also share your concerns with having to up the amount of memory for the trial version. Hmm. Maybe a GUILIBT version... with minimal but essential functions (or procs!)? And then you could tempt them in with the fact that they get the full version of GUILIB when they buy!
I am not keen on the "supplying a crunched version of the library" for all the restrictions it implies.
"Isn't it more natural for those which do return a value to be functions and those which don't procedures?"
Yes. Agreed. But my thinking was of overall standardisation. I struggle to think of a when a set of API calls don't return a value even if it is just success or failure. It is not a big issue and I would go with what you choose.
Documentation :
"Presumably not within the library itself, otherwise the size issue becomes even more important."
My initial thoughts where at least some documentation in the library. I do tend to ignore size nowadays. It really doesn't matter! And it all gets discarded/crunched anyway. I have just had my fingers burnt so many times for not documenting (or using readable variable names in) a function. I think it would also help in future maintainance. For instance in COMLIB
Code:
DEF FN_parse(O%,T%,C$,U%)
LOCAL D%,V%,R%:DIM V% LOCAL 15
D%=FN_instr(C$,".","(",")",1)
WHILE D%
SYS !(!O%+4),O%
R%=FN_checkargs(O%,3,LEFT$(C$,D%-1),V%)
IF R% THEN =R%
SYS !(!O%+8),O%
O%=V%!8
C$=MID$(C$,D%+1)
D%=FN_instr(C$,".","(",")",1)
ENDWHILE
=FN_checkargs(O%,T%,C$,U%)
Is surely a nightmare to any future maintainance guy?
"Statics? Are you in fact proposing that this library be written in C (i.e. a DLL)? "
No! LOL, although it could be done.. I probably shouldn't of said it. Ignore that one.
"Release TWO Trial versions of BB4W"
I can only think of the potential nightmares.
David "Have you changed your e-mail address recently?"
Yes. I did. I have sent you a new one. Sorry am slowly getting round to update all my contacts. I hope you understand that my bank was first!
Michael
|
|
Logged
|
|
|
|
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
|
|
|
|
|
