LB Booster - The future of LBB

LB Booster

General

Suggestion Box (Moderator: Richard Russell)

The future of LBB - please read

« Previous Topic | Next Topic »

Pages: 1 2

Author

Topic: The future of LBB - please read (Read 3265 times)

tsh73
Full Member

member is offline

Gender:

Posts: 210

Re: The future of LBB - please read
« Reply #4 on: Jan 9^th, 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

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: The future of LBB - please read
« Reply #5 on: Jan 9^th, 2014, 09:45am »

on Jan 9^th, 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.

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: The future of LBB - please read
« Reply #6 on: Jan 9^th, 2014, 10:54am »

on Jan 9^th, 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.

Logged

David P
Guest

Re: The future of LBB - please read
« Reply #7 on: Jan 20^th, 2014, 10:51pm »

Hi,

Will LB Booster's editor be as powerful as BBC Basic for Windows' editor in the future?

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: The future of LBB - please read
« Reply #8 on: Jan 20^th, 2014, 11:24pm »

on Jan 20^th, 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.

Logged

bluatigro
Full Member

member is offline

Gender:

Posts: 111

Re: The future of LBB - please read
« Reply #9 on: Jan 28^th, 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

« Last Edit: Jan 28^th, 2015, 10:07am by bluatigro »

Logged

cbrescia
New Member

member is offline

Gender:

Posts: 1

Re: The future of LBB - please read
« Reply #10 on: Jan 28^th, 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.

Logged

Jack Kelly
Full Member

member is offline
Avatar

Gender:

Posts: 106

Re: The future of LBB - please read
« Reply #11 on: Feb 7^th, 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.

Logged

SarmedNafi
Junior Member

member is offline

Posts: 93

Re: The future of LBB - please read
« Reply #12 on: Feb 7^th, 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.

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: The future of LBB - please read
« Reply #13 on: Feb 7^th, 2015, 9:03pm »

on Feb 7^th, 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.

Logged

SarmedNafi
Junior Member

member is offline

Posts: 93

Re: The future of LBB - please read
« Reply #14 on: Feb 8^th, 2015, 02:40am »

Well,

Richard are they available on BBC?

Logged

SarmedNafi
Junior Member

member is offline

Posts: 93

Re: The future of LBB - please read
« Reply #15 on: Feb 8^th, 2015, 02:43am »

I mean:

List View / Grid control

Are they available on BBC?

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: The future of LBB - please read
« Reply #16 on: Feb 8^th, 2015, 10:02am »

on Feb 8^th, 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.

« Last Edit: Feb 8^th, 2015, 10:03am by Richard Russell »

Logged

bluatigro
Full Member

member is offline

Gender:

Posts: 111

Re: The future of LBB - please read
« Reply #17 on: Aug 17^th, 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

Logged

Richard Russell
Administrator

member is offline

Posts: 1348

Re: The future of LBB - please read
« Reply #18 on: Aug 17^th, 2015, 09:54am »

on Aug 17^th, 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.

Logged

Pages: 1 2


« Previous Topic \| Next Topic »