LB Booster
General >> Suggestion Box >> The future of LBB - please read
http://lbb.conforums.com/index.cgi?board=suggestions&action=display&num=1389201278

The future of LBB - please read
Post by Richard Russell on Jan 8th, 2014, 4:14pm

LB Booster has reached something of a milestone, in that it is now being used 'seriously' rather than being just a novelty. Two large commercial applications (one of around 14,000 lines of Liberty BASIC code and the other consisting of over 100,000 lines of code in three modules) have recently been ported to LBB.

I am now starting to think about how LBB should be developed (if at all), and I would greatly value some feedback on the subject. It seems to me that there are five directions in which I might consider extending it:

  1. Additions to the Liberty BASIC language. For example it ought to be possible to support 3-dimensional arrays, e.g. array(x,y,z), or arrays of structures.

  2. Extensions to the Graphical User Interface, for example new controls such as a List View / Grid control or native toolbars and status bars.

  3. Aids to debugging (currently almost totally absent in LBB, although TRACE is partially implemented). For example Run to Cursor, Single Step or the ability to list variable values at run time.

  4. New compiler directives, such as conditional compilation (e.g. %if, %endif) or 'compiler constants' (e.g. %define) to allow different versions of a program to be built.

  5. Improvements to the IDE, such as syntax colouring, automatic indentation or aids to navigation. To an extent 'LB Workshop' (which integrates well with LBB) can already satisfy this need.

Of course I'm not suggesting that these are 'mutually exclusive' - in an ideal world they could all be addressed - but realistically I need to know which would be most valuable to users so I can prioritise the work.

What do you think? Which, if any, of these options would you prefer me to concentrate on? Or are there things I haven't thought about which ought to be added to the list?

Richard.

Re: The future of LBB - please read
Post by Phineas Freak on Jan 8th, 2014, 5:29pm

I hope that you will implement everything from that list, especially the additions and/or extensions. Compiler directives should be next.

IDE improvements and debugging tools can be postponed until later since it's possible to write the code with an external editor and debug it via LB (at least for LB-compatible code).

Unfortunately you mentioned everything that i would like the most from LBB and i don't have enough imagination to suggest possible additions to these ideas. So i will just give it a huge "thumbs up" and wish you luck! smiley
Re: The future of LBB - please read
Post by Richey on Jan 8th, 2014, 11:28pm

Richard, I'm not knowledgeable enough to give a totally informed opinion but what PreciseTiming has suggested seems reasonable to me.
Re: The future of LBB - please read
Post by CirothUngol on Jan 9th, 2014, 02:13am

Well, this is certainly fun!
I've been writing my programs to be LBB compatible ever since I found this app over a year ago. Now with the recent inclusion of really-large-string support any remaining incompatibilities should be fairly minor bugs, and I'm glad you're thinking about expanding your Booster's capabilities.
Let' see...

I would expect most users to vote for 1 and 2, because either would directly expand the language itself and everyone likes new toys! Additional or improved GUI widgets would probably bring the most interest from current Liberty BASIC users who have yet to move over to LB Booster (but of course, 3+ dimensional arrays\structs would also be nice).

However, if explicit changes or additions are made to the language itself, then items 3 and 5 go from the "nice convenience" category to the "nearly necessary" category because there won't be any other software\IDE that one could use to properly display or debug the new code. So it's rather like a double-whammy... if you do either 1 or 2, it drastically increases the need for 3 and 5.

Now with all that said, I would have to admit that item 4, New Compiler Directives, might actually be the best choice in a "time vs. effort", bang-for-your-buck sorta way. It wouldn't really require an IDE or debugger, so it could easily be fashioned to appear as a comment in other IDEs allowing you to provide this exclusive functionality without breaking syntax.

Finally, my vote is for item 3. Even without other IDE enhancements, a -D command-line option for a debugger would allow for the use of LibertyBASIC Workshop for the rest of the IDE. The inclusion of a proper debugger for LBBooster would probably be the option that I personally would use the most. It may also be a logical first-step to expanding the language itself... it would be needed.
Re: The future of LBB - please read
Post by tsh73 on Jan 9th, 2014, 04:34am

I have an idea that looks like small thing in (1), but as always may prove to be huge sad
(and of course I have no idea if it is big or small)
It is extending EVAL to
1) support user-defined functions
2) somehow allow to ASSIGN thing named in a string.
Just my 0.02$ wink
Re: The future of LBB - please read
Post by Richard Russell on Jan 9th, 2014, 09:45am

on Jan 9th, 2014, 04:34am, tsh73 wrote:
It is extending EVAL to
1) support user-defined functions

As you know, the compatibility of LBB's EVAL with LB is in any case limited, and there's not a great deal I can do about that.

However you can actually take advantage of the incompatibility in this case: if you prefix the name of the user-defined function with FN (this tells LBB that it's a function call rather than a reference to an array) it will actually work! For example:

Code:
    a = 1.2345
    print Secant(a)
    print eval("FNSecant(a)")
    end

function Secant(a)
    Secant = 1 / COS(a)
end function 

Quote:
2) somehow allow to ASSIGN thing named in a string.

You can take advantage of the same 'feature' to achieve that now as well:

Code:
    var$ = "abc"
    num = 5.4321
    dummy = eval("FNassign(";var$;",";num;")")
    print abc
    end

function assign(byref n, v)
    n = v
end function 

These are hardly 'extensions' to LBB, they are just 'accidental' functionality, but they work!

Richard.

Re: The future of LBB - please read
Post by Richard Russell on Jan 9th, 2014, 10:54am

on Jan 9th, 2014, 02:13am, CirothUngol wrote:
I would expect most users to vote for 1 and 2, because either would directly expand the language itself and everyone likes new toys!

In practice they haven't, perhaps because, like you, they worry about the debugging implications if their code becomes incompatible with LB.

Whilst I certainly recognise the validity of that concern, I don't personally feel that implementing (1) or (2) necessarily implies implementing (3) as well. Although LBB lacks a debugger, run-time error messages often include the line number, and of course adding temporary debugging code to the program itself (such as printing variable values to the mainwin) can be very helpful in locating a fault.

Quote:
Now with all that said, I would have to admit that item 4, New Compiler Directives, might actually be the best choice

That is looking to be the consensus, both here and on the Yahoo group. What directives would be most valuable?

Quote:
it could easily be fashioned to appear as a comment in other IDEs allowing you to provide this exclusive functionality without breaking syntax.

I had anticipated extending the syntax used for the existing %mode directive, so it wouldn't be compatible with LB, but then I assume the directives (e.g. conditional compilation) will usually be essential for creating a valid program anyway so if LB ignored them the code still wouldn't run.

Quote:
a -D command-line option for a debugger would allow for the use of LibertyBASIC Workshop for the rest of the IDE.

LBB does recognise the -D command line switch, for compatibility with LBW, but currently it just loads the program and waits, so you can take advantage of the limited 'manual' debugging facilities currently available.

Richard.

Re: The future of LBB - please read
Post by David P on Jan 20th, 2014, 10:51pm

Hi,

Will LB Booster's editor be as powerful as BBC Basic for Windows' editor in the future?
Re: The future of LBB - please read
Post by Richard Russell on Jan 20th, 2014, 11:24pm

on Jan 20th, 2014, 10:51pm, Guest-David P wrote:
Will LB Booster's editor be as powerful as BBC Basic for Windows' editor in the future?

The two editors are very different: the BB4W editor is entirely custom code, which allows for things like 'live' indentation, whereas the LBB editor is a standard Windows RichEdit control, which means it supports more mouse commands, a wider range of fonts etc.

So depending on what particular features you are interested in you may consider the BB4W editor to be more, or less, powerful than the LBB editor! Because of their incompatible implementations, they are bound to remain quite different.

I might have been interested in using Scintilla for the LBB editor (rather as LB Workshop does) but I particularly want to retain support for bi-directional text (e.g. Arabic or Hebrew strings) and, as I understand it, Scintilla doesn't do that.

Richard.
Re: The future of LBB - please read
Post by bluatigro on Jan 28th, 2015, 09:51am

i wood like :
- OOP : operator overloading
- %ifnotdefined
- %define
- %endif
- nested 'include
- pi , true , false as global consts [ whit diferent color ]
- open gl + consts [ whit diferend color ]
- 4 axel joystick reading + more buttens
- wireles com [ bluetooth or wifi ]
- sprites :
- "spriteimage? spr img$"
- "spritescalexy spr x y"
- "spritescalexy? spr x y"
- "spritehit? spr whitspr bool"
- "spriterotate spr deg"
- "spriterotate? spr deg"
- numbers in diferent color
- &hff type numbers
Re: The future of LBB - please read
Post by cbrescia on Jan 28th, 2015, 5:31pm

I think that compatibility with LB4 should be kept, however, on the other hand, LBB could add and enhance the language and tools.
Add new GUI components could create added value for the product.
For example having a "RealNumber, realvar" component could be a big difference with any compiler I knew.
I think Microsoft considers subclassing and filtering the edit component one of the most natural things to do, but since I work daily with real numbers, not "numbers" with alphanumerics from 0...9, to me is not. And I never saw a language with a GUI for real numbers input. Think of it as a small 1x1 Grid. That's why my first choice for rapid programs calculations is a spreadsheet!
A LBB with this option would be my first choice.
It is just an idea.
Re: The future of LBB - please read
Post by Jack Kelly on Feb 7th, 2015, 06:25am

I vote for #5, improvements to the IDE. That is where we spend most of our time. I have looked at LB Workshop, but have not embraced it yet. I really don't want to add another layer to my working environment.

Re: The future of LBB - please read
Post by SarmedNafi on Feb 7th, 2015, 5:58pm

> Extensions to the Graphical User Interface, for example new controls such as a List View / Grid control or native toolbars and status bars.


I prefer to insert this extensions indeed, it will be a big jump over LB, I will leave LB behind me and go faster with LBB.
Each time Richard say that then he fold back for some reasons.
I hope this time will be the big band of LBB.
Re: The future of LBB - please read
Post by Richard Russell on Feb 7th, 2015, 9:03pm

on Feb 7th, 2015, 5:58pm, SarmedNafi wrote:
> Extensions to the Graphical User Interface, for example new controls such as a List View / Grid control or native toolbars and status bars.

This thread is very old; there is a gap of more than a year between reply #8 and reply #9! So whilst it is interesting to get responses after such a long time, bear in mind that a lot of water has passed under the bridge since then. In particular see the thread Winding down LBB for a change of direction.

So, although one should never say never, I think it's now very unlikely that LBB will ever be extended to incorporate native List View or Grid controls.

Richard.

Re: The future of LBB - please read
Post by SarmedNafi on Feb 8th, 2015, 02:40am



Well,

Richard are they available on BBC?


Re: The future of LBB - please read
Post by SarmedNafi on Feb 8th, 2015, 02:43am


I mean:

List View / Grid control

Are they available on BBC?


Re: The future of LBB - please read
Post by Richard Russell on Feb 8th, 2015, 10:02am

on Feb 8th, 2015, 02:43am, SarmedNafi wrote:
List View / Grid control. Are they available on BBC?

The List View is a standard Windows control, so it is available to any language which supports calling the Windows API - and that includes both BBC BASIC and Liberty BASIC. Indeed, demo programs which use a List View control are available for both those languages.

The issue is not whether the List View is available but whether it is supported as a native (built-in) control. BBC BASIC has no built-in controls - it's not a Windows language after all - the only way of creating any standard UI feature (even something as simple as a textbox) is via direct API calls - although these will usually be in a library to isolate the user from the low-level complexity.

So if you want to use a List View in LB 4.04 or LBB go ahead, but I have no plans to make it available as a native control.

Richard.
Re: The future of LBB - please read
Post by bluatigro on Aug 17th, 2015, 09:11am

i want to do :
Code:
for i = 0 to 5
  button #m.btn;i,str$(i),ul,btn,i*50,50,50,50
next i
wait
sub btn h$
  b = val( right$( #h$ , len( #h$ ) - 5 )
  notice "you pushed button " ; b
end sub
 

this kind of code i want to do whit all the GUI controls

in the IDE i want more than one texteditor-page
so i can load more codes at one time
Re: The future of LBB - please read
Post by Richard Russell on Aug 17th, 2015, 09:54am

on Aug 17th, 2015, 09:11am, bluatigro wrote:
this kind of code i want to do with all the GUI controls

Yes, you can! LBB already supports that:

Code:
for i = 0 to 5
  button #m.btn,str$(i),btn,ul,i*50,50,50,50
  maphandle #m.btn, "#m.btn";i
next i
open "Multiple buttons" for window as #m
wait

sub btn h$
  b = val( right$( h$ , 1))
  notice "you pushed button " ; b
end sub 

Richard.