thinBasic 2.x direction [Archive] - thinBasic: Basic Programming Language Community Forum

View Full Version : thinBasic 2.x direction

ErosOlmi

06-07-2010, 11:58

Hi all,

summer is already with us. I will be on holiday in Spain from the 24th of July till the 8th of August.
I will have my laptop with me but in the above period my activity on the forum will be limited to check forum functionality.

Before the above period I think I will release a final 1.9 definitive, ultimate, no looking back, last version ;)
I know, I said that before but I didn't want to left a 1.x version with known important bugs inside. Now I'm quite satisfied of current beta 1.8.x so I'm confident I will be able to close this development line.

So, what about start talking for the next thinBasic 2.0 direction and exchange ideas and/or requests for the autumn/winter/next years development time ;)

I have some ideas but mostly they are related on internal thinBasic Core organization. I will summarize them here but I would like to have this thread open to all of you to post whatever idea even the most mad or impracticable (I already did my best below :shock: ) or even critics on what thinBasic has been and what you would like it to be. A kind of open mind brain storming where to put all and at the end get what is best suitable or shared by many.

Please, please, please! I posted this thread in "Vaporware" forum.
Take my ideas and whatever we will talk about here as brain storming and not like stones. All can change and/or nothing will change

So far, my ideas are the following:

1as you know thinBasic has been developed using PowerBasic and started with PowerBasic 8.x At that time PB had no OOP. Starting from PB version 9.x OOP started to see the light. I will take advance of it converting internal thinBasic Core engine from global variables and UDT to Classes and Interfaces. thinAir is already programmed with this logic in some of its parts. I will extend it to thinCore and thinDebug

2The above new internal code organization will open to door to multi-threading, so it will be possible to have threads in scripts and have parallel script functions executions

3For all module developers: the above will change all thinCore SDK functionality because it will be necessary to pass 1 or 2 additional parameters to all SDK functions. Something like script ID and thread ID. But on this I need more time to be sure what it will need

4CODEPTR to script functions. I think I've an idea on how to calculate and wrap code pointers of script functions and be able to interface to external libs that need a pointer to a function

5A native interface to COM components more or less like scripting languages like VBScript or other COM aware languages do. A simple dotted notation without all the current not user friendly thinBasic COM module functionalities

6Some kind of OOP in thinBasic. This is something I already wanted to start some time ago but always stopped myself to start because I knew it would be a long never ending road so I wanted to finish 1.x development line before even start talking.
It will be not easy, it will be necessary to change a lot internally (Core engine) but something to definitely talk about and choose a possible direction

7thinAir project handling able to summarize all the options of a project from resources to bundling

8thinAir plug-in system. So open to all programmers able to develop a DLL the possibility to add plug-ins to thinAir able to interact directly with script sources

9Improved thinBundle:

9.1 add application icons
9.2 add application resources
9.3 options for each of the bundled files (compress, extract, delete, ...)
9.4 "extract" the DLLs and EXE in memory instead of hard drive.
9.5 "extract" script into memory instead of hard drive.

10Exception handling: see below Petr's description

11An official uptodate and supported SDK for a free C/C++ language.

12read C headers directly (as well as its own Basic headers).

13Named Parameters

14Explicit line continuation (mainly already in place in thinBasic 1.8.6.0)

15Assignment vs Equality Operators

16Local Functions

17Dynamic scoping

18Closure

19Use XML as possible thinBasic source code format. This would allow to include inside source code a lot of other possible informations like comments, descriptions, debugging info, data (in general) to be used at runtime, files, and even binary data

20Being able to create a thinbasic script at runtime dynamically and let it run or use it as a function

xxxI call this last line of the table as xxx because it can be hot but please, please, please (again) take it as option on the table to throw away at any time: possibility to change development language used to develop thinBasic.

I love PowerBasic at the max, it is my preferred programming language. I would suggest to every programmer to spend to buy it without any any hesitation.

But thinBasic is something different and I would like it to be something more in the future: more open to different platforms, more open to 3rd party libs, more open to additional module programmers.
As far as we can see and have seen during recent years PB will not open to different platforms. Maybe it can change and I will be happy if it will happen but we cannot wait forever. The same for 64bit: it will happen, maybe this year, maybe next year but again we have to see a little ahead.
So this point is just to say that this option is on the table. Maybe I will never change but if the conditions will demand or will be favorable, why not. And if yes, where to look at.

ADDED: this point doesn't necessary refer to thinBasic version 2.x but is an open point always valid as possible consideration.

Ok, I will stop here because the above points can have work for more than ... many years or more.
I will wait for your mad comments.

Ciao
Eros

Petr Schreiber

06-07-2010, 13:43

Thanks a lot Eros,

this look to the future was long awaited, and I am happy to see it so nicely summarized here.

Ad 1
That sounds great. I am more and more getting used to OOP style of coding, so this is definitely good idea

Ad 2
Yes please :lol:

Ad 3
No problem.

Ad 4
Again great.

Ad 5
Sounds good to me, I did not used third party COM libraries yet, but dotted syntax is the way for this.

Ad 6
This is funny. When I started on ThinBASIC project, OOP programming was pure evil in my eyes. With the years I am more and more fascinated by this concept, and I am 100% voting for having it in ThinBASIC. I did brief PDF proposal about OOP model in ThinBASIC, I removed the dust from the file and attach it here. The 50% of PowerBASIC for me are the fantastic, unmatched José Roca headers.

Ad 7
Very good to have.

Ad 8
Very good to have.

Ad 9
Especially the icon and resources would be appreciated.

Ad xxx
This is interesting point and something to think about. I also love PowerBASIC to the max, especially the version 9 got me excited.
I like its string handling, inline assembly, the introduction of OOP model and on the first place - rock stability.

In the past years I tried various other languages, as part of school classes or during my own investigations.
I must say I found just 2 tools which got my attention (when I do not count pure thinBasic itself):

C#
Oxygen

The first one because it was the first languge where OOP made sense for me. But for our purposes it is something not usable, as it has .NET dependancy, and the work with strings is very weak, especially for people used to BASIC. +/- the same for Java - requiring Java installed could be problem, I am personally quite annoyed by agressive Java on task bar on laptops, if I need it for some applet I install it, try the applet, and the uninstall.

The Oxygen is converging very well to compiler of my dreams - it has OOP very close to C# model I like so much, it has BASIC syntax, it can create DLLs and now it can compile bith 32bit/64bit EXEs and Charles is man-compiler and reliable guy. The only problem I have with Oxygen, is the lack of documentation and proper IDE + debugging tools.

I am not sure if these solutions are already mature enough to hold the thinBASIC project on its shoulders. In my experience, C# programming flows very well, but there were some reliability issues (maybe more related to .NET as such), which keep me off using C# for projects I would consider selling or sharing with other people. Oxygen is great as I said, only the mentioned (definitely solvable) problems make me undecided. I cannot judge the stability, as I use it for little tests.

That is why I still use PB9 for TBGL development, I trust the tool and it is documented.

For me, the press on multiplatformity is not so big. If I would say one, it would be Linux, but I am not using it too frequently. I usually install it, play with it and remove it again. I am sure ThinBASIC could become a star on Linux on the other side... I still remember E.K mentioning the lack of Linux port the only problem :)
The 64bit Windows question is more interesting to me for the memory it can allocate.

Last note regarding the portability across the OSs - it would mean having module of UI not based on catching Windows messages, but working in more abstract way, like Delphi/VB/C# did - that means handling events using OnClick and other automatically fired callback functions not dependent on platform.

Ad 10
There is one thing I would add to the magic list, and that is Exception handling, I summarized it a while ago, and still think it is good feature to have:
Exception handling proposal open for discussion (http://community.thinbasic.com/index.php?topic=2948.msg22468#msg22468)

Petr

zak

06-07-2010, 15:30

Hi Eros,
i suggest that there may be always a ghost thinbasic ship made from other materials and lurking behind the clouds waiting for a call on emergencies. it can be a kind of a gymnastic exercise .
the materials; i looked at http://en.wikipedia.org/wiki/List_of_compilers
could it be free pascal ? it has 32 and 64 bit support, and have OOP,
purebasic ??...,
other suggestion: is to make another support site for thinbasic on a famous free groups such as yahoo groups; i said that because i have seen a successfull BCX discussion group site there discussions, files, pics, http://tech.groups.yahoo.com/group/bcx/ it is running from year 2000 until now.
regarding linux, i have installed it before a month, and believe me i feel in this environment like a guest in a poor house; no chairs, no TV, no cola, poor nvidia support, i can't run the sound, every thing done in a hard way... etc. i feel always thirst with a dried throat while i am in this OS, while in ms windows it is like Bill Gates casting his richness and comfort on his product. but whatever the situation it is good to support linux since it means from a philosophical viewpoint that thinbasic have more horizons and lookouts and ways of doing things.
thanks

ErosOlmi

06-07-2010, 15:43

Free pascal was under my attention. Strings handling is not bad

jcfuller

06-07-2010, 17:12

xxx
My number one compiler for Windows is still PowerBASIC, but without 64bit and no Linux I have been experimenting with other avenues.

If you are looking for ideas take a look at the direction I went using wxWidgets and the Bcx Windows and Linux translators.
BcxWx: http://www.basic-compiler.com/forum/
c++ based using this compiler: http://tdm-gcc.tdragon.net/

The source for both Bcx Windows and Bcx Linux is provided so you may be able to get an idea on direction.

The wxWidget library has much more than just UI. String handling is not too bad but not on a level with PB.
A lot of built in functions!

James

JosephE

06-07-2010, 18:58

I really liked Petr's proposal on OOP.

However, in my humble opinion, if you were to rewrite all the modules and functions to act as objects, it would make it much less easier to use for new programmers. It's one thing to learn a command, it's another thing to learn an entire system of objects. Besides, who wants to make a FileHandler object that requires an instance of a File object before you can read and write from a file? I love OOP, but it can be overkill.

That's one of the problems I have with OOP. I never know what to make an object, and what not to. It takes so much planning that I never get to do any programming. At least for me. Most things don't need to be an object but in an object oriented environment, your code is considered disorganized unless it's in classes.

I think if we do have support for objects, they should be optional (and we definitely need static classes - having to make a FileHandler object instance just doesn't make sense to me). I think the default modules that come with thinBASIC need to stay the way they are personally. But then some could argue that this turns into PHP - class support but a standard library that doesn't even use it.

Michael Hartlef

06-07-2010, 19:41

All sounds great. But I will just comment on the cross platform thingy. You know that I would love to see thinBasic running on my IMac natively. Any other platform would be awesome and someone that make it stand out to the competition even more. The WXWidgets suggestion should be looked at seriously if crossplatform development will be on the list. Regarding switching development languages? Switch only if you want to support other platforms. There my suggestion is either C++ or FreePascal. Both are available for free, matured and developed and run on most platforms.

Petr Schreiber

06-07-2010, 22:48

JosephE,

I agree with you, in some places OOP is not necessary. But it would be good to have it in arsenal in case you need it.

Petr

jcfuller

06-07-2010, 23:22

You could always fork with 2.0.
1.0 stays the way it is with minor additions while 2.0 becomes the oop/crossplatform version with no need to follow any of the 1.0 format?

James

John Spikowski

07-07-2010, 01:00

Eros,

Personally I would like to see you invest your talents in a cross platform interpreter and ScriptBasic is a great foundation with unlimited potential. You have done an outstanding job with thinBASIC but due to the compiler you're currently using, you hit the wall. (no cross platform support, almost 10 years behind the curve, end of life cycle) If an already existing open source interpreter isn't your cup of tea, then using James Fuller's suggestion of BCX/wxWidgets to give you a C environment to play with sounds like a great choice as well.

kryton9

07-07-2010, 02:21

You guys know my feeling as I harped about it for a few years now, so I won't repeat any of that.

There are 5 options from all of the tests I have done.
1. .net using mono and monodevelop
2. java
3. freepascal/lazarus
4. oxygen
5. c++

Java is already outdated if you ask me and nowhere as fun to work in as .net or lazarus.
But Google selected it and it means it will be here for some more time. But I can see the signs on the wall that this will not be number one much longer. More and more blogs are pointing out frustrations with Java and how it is falling behind and getting too complicated trying to keep up with current programming methodologies.

Mono is growing by leaps and bounds. It has really surprised me. Monodevelop is a wonderful IDE. Mono is appearing on mobile devices on top of the popular OS platforms. The only drawback is if Microsoft one day puts it foot down on mono's throat. Many say if they wanted to do that, they would have done it already and that it is not a concern. But when you see mono work as well as it does... I don't know and trust Microsoft.
If you want to see an incredible Mono application look at the free trial of Unity. It allows you to compile your games to any platform and soon Android too, this all because of the incredible mono team and all that the unity team has brought to mono also.
Mono supports all of these languages too at this time:
http://www.mono-project.com/Languages
So this way tb2 development can grow a lot quicker with developers coming from different language backgrounds righting modules for .net.
One last thing... Mono uses GTK which is a really sweet looking cross platform GUI that looks modern and fresh.
But Mono does have Visual Basic support, so does making another basic makes sense, tough call?

freepascal /lazarus... incredible package. But I did find developing on windows and going to other platforms does not work well. You have to develop in Linux and then you can compile to windows and mac osx. There are people getting it running on Android devices, but not a mainstream feature right now and easy to do. So to do true cross platform development means working in linux as your main development environment to make sure you can cross compile without pulling your hair out.

Oxygen - Can be cross platform, but not yet. Doesn't have an editor as nice as any of the other mentioned platforms.
Java, Mono and Free Pascal already have incredible IDE options. But I think Oxygen can be the core to a new way of programming, all the power without the scary syntax. The core and tb2 on top can be a truly unique looking and feeling powerful OOP language. But as Petr mentioned... it is up to you and Charles to evaluate its foundational strengths and if it is ready.

If you feel that Mono is safe from death by Microsoft, I would say that would be what I see as a platform right now with a bright future and ready to use right now. It has grown by leaps and bounds and surprised me so much. I think you all will be shocked too if you look at it more closely.

Of course there is the powerhouse c++, and if you want to see how good c++ code can be written and the type of modules you could create, I highly recommend looking at SFML and its source files. The nicest code to highlight how c++ can be not bad to work with.
http://www.sfml-dev.org/download.php

But cross platform and getting different cross platform libraries to work is not easy. Also you have different coding styles to deal with according to what the developers of those libraries chose to use with c++.

But c++ is very flexible and has grown on me. String handling is still a joke. You need to use Boost as well as the STL string libraries. Boost has what is called Lexical-Cast, that allows you to do all of the type conversions.

If you want to write once and compile anywhere, then I would recommend freepascal/lazarus. The windows version has many more components than the linux version and that is why I think Remmer did not cross compile. If you load up the linux version, you see there is a lot less installed and the platform I would use to develop in to be safe.

kryton9

07-07-2010, 03:21

The last one got long, so I thought I would post this one.
One thing to do perhaps before making a decision is to write like a string module in each of the listed systems to see what working in each is like. See how well you can get it to cross compile and run in windows, osx and linux. Probably the only way to really make a decision and to get a feel for what feels right for you Eros.

Code::Blocks is a really nice IDE for c++. Available in 3 major OS platforms. Uses gcc compiler, but can be set to use others.
Has intellisense, which once you get used to it, hard to live without. Lazarus has this too for freePascal.

To keep thinBasic2 really unique, if Charles can make oxygen run on osx, linux, then that might be worth working on. I think Oxygen from the start is so fresh and neatly well thought out, that it would be a neat core to build a new cross platform (oop optional) true compiled BASIC such as TB2.

zak

07-07-2010, 05:07

1.0 stays the way it is with minor additions while 2.0 becomes the oop/crossplatform version with no need to follow any of the 1.0 format?
James
last night i came on with approximately this same idea, this is the same strange case of perl development, there are 2 production lines, v5.x which depends on C compiler, and v6 which depends on Parrot compiler, most users of v5.x will never use v6 but v6 considered the future and a new vision, every 3 months there are a new fraction added to the oldy v5.x edition and there are infinity between number 5 and 6,
so the same can be for thinbasic, 2 production lines, the normal one which are currently used, we can't get rid of the amazing recent RichEdit additions developed in one long night, and the visionary flavour which may developed independently of the normal edition and slowly without pressure. the two editions can benefit from each other like neighbors.

kryton9

07-07-2010, 06:08

One thing also to consider for c++... for instance Irrlicht which is cross platform for major OS's... it's gcc irrlicht.dll is three times the size of the dedicated MSWindows irrlicht.dll.

Another thing to mention, if Java is being thought of... that is try to get the Monkey Game Engine(jME) running with Java, if you have any doubts of how crazy Java development is. After 15 years, you would think they would have found an easier way! But java has Jabaco as .net/mono has VisualBasic, can the new TB2 be so different than those on those platforms?

This leaves, c++, freepascal and oxygen if you look at it like that. It will be a tough decision but an exciting time to be thinking about the future of TB2.

John Spikowski

07-07-2010, 06:15

I can't imagine Eros starting from scratch using C/C++ for 2.0 thinBASIC. A good way to get there is to use BCX to translate the PB thinBASIC code to C and then maintain the code for thinBASIC in C/C++ going forward. BCX started off as a PowerBASIC clone attempt way back when but has evolved beyond the limitations in PB.

ErosOlmi

07-07-2010, 08:17

Great ideas and informations. Thanks.

In any case this is what will happen soon (before I will leave for holidays):

as I stated above, version 1.x (I think it will be 1.9.0) will have a natural end very soon because it will sign the last thinBasic version able to be executed under Windows 9x, Windows 2K environments.
This version will remain always available in download section for those that needs backward compatibility.
I will continue to work on this version only in case of important bugs and help material but I will not add or improve any feature
I will in any case start a new thinBasic development line 2.x always under my beloved compiler Power Basic.
thinBasic 2.x will be compatible only under OSs from Windows XP or above.
This will immediately open the possibility to thinBasic module developers to work on features not present till now due too Windows 9x limitations like GDI+ and other options available only in Windows XP or above OSs

That said, the idea to open an additional experimental development line is not bad at all.
Before been able to get any decision about other directions, I need to test the basis of thinBasic Core engine in other environment so it is necessary to experiment good strings lib, replicate or create internal Core structures used by thinBasic engine (mainly hash tables), learn different languages (I think I can understand many different languages even if I've never programmed with them but writing serious code is a different matter), check possible UI direction (I do not want thinBasic be only a console script language in other OS).

So, thanks again for already expressed ideas info reported here and thanks in advance for the others that will come.

Ciao
Eros

Petr Schreiber

07-07-2010, 08:46

Add 9B
Maybe one more idea we discussed earlier - "extract" the DLLs and EXE in memory instead of hard drive.
It could be slightly faster, but in the first place it would avoid confusion of users which sometimes get scared when they launch bundled EXE and it starts populating the directory with "odd files".

Petr

John Spikowski

07-07-2010, 09:19

I will in any case start a new thinBasic development line 2.x always under my beloved compiler Power Basic.

:talk38:

Great, another round of limitations and no future with the tools you use to build thinBASIC.

How many times does it take getting stung before you no longer feel the sting?

ErosOlmi

07-07-2010, 09:40

John, this is a brain storming thread. No negative reply please only neutral or positive. If not so, please do not post in this thread

There will be time for making a change. As I stated in my first post here: "All can change and/or nothing will change."

Consider the following:

moving from 1.x to 2.x with the same compiler is 1 hour job for me and the whole thinBasic community can immediately move on and be operative with new possibilities. It is a natural option for not having a gap of months in development, it is easy and well known path
moving into another development environment will be a long process of experimenting and experiencing. I do not want to have such a big black hole timing for thinBasic users. I'm not that kind of programmer that move from one environment to the other every week. I tend to spend much more time on software selection valuating all possible pro and cons but once the choice is done I stay there.

Ciao
Eros

John Spikowski

07-07-2010, 09:53

John, this is a brain storming thread. No negative reply please only neutral or positive. If not so, please do not post in this thread

So references that the king has no clothes is OT? Please be open minded and and hear all possibilities. PowerBASIC has generated enough cash that they don't need your unpaid protection. Censorship creates limitations.

ErosOlmi

07-07-2010, 10:11

Please be open minded and and hear all possibilities.

John ... JOHN

it is exactly one of the purpose of this thread: "open minded and hear all possibilities".
Instead, with your post you are jumping to the conclusion :x

Maybe what you suggest will be the choice (if there will be a choice) but not now.
Now it is time of "open minded and hear all possibilities" but this will not stop going on of thinBasic project.
There is no need to stop all. While I will go on (this is a live project still full of passion from my side) we can discuss about possible futures (multi tasks, multi threaded mind :D ).

Ciao
Eros

John Spikowski

07-07-2010, 10:18

How can you say your open minded when you have already made up your mind?

Why not take what you learned building thinBASIC with PB and share that knowledge as a mentor and let your friends help you build 2.0 in an open source environment?

I don't see much difference upgrading from 1.x to 2.x with the SMF forum and upgrading thinBASIC to 9.x of PB. Not much gain even if there is little pain.

ErosOlmi

07-07-2010, 11:14

How can you say your open minded when you have already made up your mind?

You are making a mistake, maybe because you do not follow our discussions here too much frequently.

We are moving to thinBasic version 2.x to stop support for Windows 9x (not PB 9x) and Windows 2K OSs
This will open the possibility to use API and libraries only available on Windows XP or above.
This move has already been declared and discussed many months ago with those developing thinBasic module and they were still waiting for this to happen. Now we are just put it in practice.
STOP. This it is simple, isn't it?

The rest will come maybe thanks to this discussion.
There is no decision for future and in any case whatever decision will be taken it will require time to put in practice.
What do you want thinBasic would be in the meantime? A dead project? A stopped project? A project in the "limbo" waiting for a decision? A project waiting the programmers understand a new development environment?

No! Nothing of the above.
I will continue to develop thinBasic as much as I can to give thinBasic users the best feature I can and/or they ask for and at the same time, take a decision, understand what is needed to be understood and hopefully having something new to work with after all those effort.

John Spikowski

07-07-2010, 11:56

Sorry, the way you present the 2.0 story is your looking for ideas and direction. You then followed up with the statement that PB will continue to be the foundation of thinBASIC.

So, what is this thread about anyways? It's hard enough finding resources to help out with projects and no one likes doing things twice or in parallel.

When you're ready to talk about a more open and broader coverage direction, I'll be happy to contribute.

zlatkoAB

07-07-2010, 17:26

From my point of view best option is stay with Power Basic.

kryton9

07-07-2010, 17:34

I am going to post this since I made the example before reading the current posts for today.
Here is a little sample code I put together to show the power of c++ and handling string conversions from numbers to strings.
This example although short shows a lot of the power of c++ with macros and function overloading. Hope it helps others
that are thinking about platforms and languages.

//Headers
#include <iostream>
#include <string>
#include "boost/lexical_cast.hpp"

//Macros
// create my own Str$() with a Macro
#define s$(x) str(x)
// create my own Print command with a macro
#define print(x, y) cout<< x << y << endl
// print a carriage return line feed
#define crlf$ cout << endl;

using namespace std;
//overloaded function declarations
string str(float value);
string str(double value);
string str(int value);
string str(long value);

//Main function
int main()
{
cout << s$(12.35f) << " float" << endl;
cout << s$(12.35) << " double" << endl;
cout << s$(1235) << " int" << endl;
cout << s$(1235) << " long" << endl;
crlf$;
print(s$(12.45f)," float");
print(s$(12.45)," double");
print(s$(1245)," int");
print(s$(1245)," long");
}
//Function implementations with overloads
string str(float value)
{
return boost::lexical_cast<std::string>(value);
}
string str(double value)
{
return boost::lexical_cast<std::string>(value);
}
string str(int value)
{
return boost::lexical_cast<std::string>(value);
}
string str(long value)
{
return boost::lexical_cast<std::string>(value);
}

I will attach a screenshot of the results of the output and the code in code::blocks.

kryton9

07-07-2010, 17:42

I guess there was some misunderstanding... I too like John thought this was more of an open discussion. At least that is what it read like in the original post. Today's post point to what we had talked about on google wave earlier, that is PB as foundation language, windows only... as you know I think this is a dead end in the long run and puts off moving in a big way to a long bright future on another foundation. But this is not my language and not my project, so I respect the decisions you make Eros. It is your time and hard work that goes into it and you obviously should work in a way that makes you happy.

ErosOlmi

07-07-2010, 18:06

Ok, maybe it is me that I'm not enough clear or my bad English.

This is an open discussion to collect and exchange ideas.

In the meantime thinBasic project has to continue its standard life. And its natural continuation is to do what we talked about many time: release a last (possibly) bug free 1.x version that supports Win9x systems and start version 2.x compatible only with Win XP or above.

I suppose you all will agree with me that I cannot stop the project only because we are discussing about possible futures. Talking about possible futures will take some time (some weeks). Making tests on whatever other direction will take some months. Having something working prototype would take many months.
Do I have to stop all in the meantime? No, of course.
Maybe someone would be happy to see this project abandoned or stopped for months but this is not going to happen :D

Is this something too complex to get?
Did I expressed my point in so bad English?
Will my point of view stop about the possibility to freely talk about anything else? I hope not.

Michael Hartlef

07-07-2010, 18:26

Eros,

I don't have a problem how you have expressed yourself and I think I understand you pretty well. I think it's their expectations or wishes that might have blocked people them from reading what you wrote correctly or like one did, digging up old war fields.

Kent wants a compiled thinbasic .net. John wants us to use script basic. And I want a money shitting donkey :) So what.

Seriously, thinbasic will enhance in one way or another. I think it is great that Eros lets us state our wishes. Changes won't happen over night and have to be planned for a long time.
They might come true, they might not. thinbasic is still an awesome interpeter language with features you don't see elsewhere.

Anyway and another seriously thought... before you add more different stuff to thinbasic, you should really think about if you want to go cross platform. If not, then stay with your current compiler you use. You know it, you like it, point blank. If you want to go cross platform, I would work on it as soon as thinbasic hits 1.9. The more you add to tb, the less you will ever start porting it to a different language/platform. Imho, that would be the first choice to make. Personally... I would not do it. I can only imagine the amount of work and my neck hurts. Plus when I see how many users we have, I doubt it is really worth it.

Michael Hartlef

07-07-2010, 18:30

Here is another wish for thinbasic:

An official uptodate and supported SDK for a free C/C++ language. I seem to be to stupid to create an import lib for Dev C++ or MingW and so would be very happy to see this one day.

kryton9

07-07-2010, 19:39

I posted my thoughts based on the xxx section of the original post

xxx I call this last line of the table as xxx because it can be hot but please, please, please (again) take it as option on the table to throw away at any time: possibility to change development language used to develop thinBasic.

I love PowerBasic at the max, it is my preferred programming language. I would suggest to every programmer to spend to buy it without any any hesitation.

But thinBasic is something different and I would like it to be something more in the future: more open to different platforms, more open to 3rd party libs, more open to additional module programmers.
As far as we can see and have seen during recent years PB will not open to different platforms. Maybe it can change and I will be happy if it will happen but we cannot wait forever. The same for 64bit: it will happen, maybe this year, maybe next year but again we have to see a little ahead.
So this point is just to say that this option is on the table. Maybe I will never change but if the conditions will demand or will be favorable, why not. And if yes, where to look at.

I was surprised when I read this-- as before, I had thought that PB was set in stone-- as was Windows only, and so I stopped asking for anything else. But when I read that, I thought I should put in what I found out from really playing with a wide range of frameworks as I do and did.

I am glad Eros that at least you listed your thoughts about vaporware ideas for TB2. It is refreshing to see a developer be so nice as to share thoughts no matter how wild.

zak

08-07-2010, 08:40

Hi
while browsing the list of compilers i have noticed the strange name "HASKELL" , so clicking on it then on its site: http://www.haskell.org , it turns that haskell are used a lot, in youtube there are some demos, like http://www.youtube.com/watch?v=gVLFGQGRsDw which display the making of mario bros game in haskell, he refer to the tutorial http://learnyouahaskell.com/
also there are a page:
Writing A Lisp Interpreter In Haskell:
http://www.defmacro.org/ramblings/lisp-in-haskell.html
he present his interpreter as a single small 784k exe here:
http://www.defmacro.org/ramblings/lisp-in-haskell/blaise_exe.zip
http://www.defmacro.org/ramblings/lisp-in-haskell/blaise_src.zip
i have tried the lisp code:
(* 12345678933334444444444444444444444444555555566677 987654321888888888888888888888888888888888888888888888888888888888887766554)
and it gives the answer:
12193263155160371823320617283950617284060356664033525387252111111111097255124917209301109382716049382716049258012160357521058
also there is a page about using opengl in haskell:
http://www.haskell.org/haskellwiki/Opengl
i have found a beautifull small haskell opengl shooting game single small 1.33 MB exe with source: http://www.geocities.jp/takascience/haskell/shu-thing.zip
he supplied the process of making exe from source like this:
ghc gl.hs -package GLUT -fglasgow-exts -o shu-thing.exe
other discussions on using opengl: http://twoguysarguing.wordpress.com/2010/02/20/opengl-and-haskell/

so may be this language deserve checking, it has a comittee conferencing once per year.
if someone want to test it , download its compiler version 2010.1.0.0 - 69 MB from here: http://hackage.haskell.org/platform/
they will release another version by the end of this year ,this is the compiler ghc, and inside there is an interpreter for interactive sessions ghci, there are also a small interface for the interpreter http://code.google.com/p/winghci/ for easy using on windows.
there are many books about haskell. so it may deserve a look.
if someone have seen others using it for programming please post.
thanks

John Spikowski

08-07-2010, 09:05

zak

08-07-2010, 09:28

the way you talk john make the listener to go right if you say go left and vice versa, i do not see you have much visitors on your script basic site , there are very little messages on your board:

http://img251.imageshack.us/img251/8841/scriptbasic.png

so i suggest for the memebers of this forum to vote if they want to cancell your membership in this forum because your postings are realy SPAM.

John Spikowski

08-07-2010, 10:05

i do not see you have much visitors on your script basic site , there are very little messages on your board:

I'm seeing 4 to 5 downloads and 200+ unique visitors a day. There really isn't much of a learning curve using the command line interpreter. The software is well document from the user and developers standpoint. Most of the posts I get are how to setup the ScriptBasic webserver and an occasional question about an extension module.

so i suggest for the memebers of this forum to vote if they want to cancell your membership in this forum because your postings are realy SPAM.

So when did promoting a open source FREE Basic become spam? You're an idiot and don't have a clue what you're talking about.

Petr Schreiber

08-07-2010, 10:43

originally reply to message which has been removed by request of its author

Hi Michael,

I do not want to lock topic on thinBasic future yet, but I am also disappointed by behaviour of one of the posters in this thread. I believe that people can change. So far it does not converge but I will keep my fingers crossed.
I would just like to ask the person to control a bit more, I haven't heard statements like "You're an idiot and don't have a clue what you're talking about." since high school, and I think they do not have place in discussion between two mature human beings.

I am happy to see ThinBASIC already used for my hobby, rapid prototyping and commercial projects. I think the proposed list by Eros will make coding in TB even more pleasure even if it would fullfill just 50% of it. To add to cross platformity, maybe it is useful to say all my TB projects ran well on Ubuntu via WINE, and all the time I was on Linux, I scripted the tasks using TB without observable speed decrease (guys do good job on WINE). That is why I am being sceptic regarding the ports to other platforms.

Ad 10?
Mike Hartlef made good point regarding SDKs - I think it would be nice to keep it up to date for all the languages, C/C++ inclusive. I was thinking about language independent XML format for the thinCore, from which the other versions of include files would be generated all at once automagically. What do you guys think?

Petr

John Spikowski

08-07-2010, 11:52

I haven't heard statements like "You're an idiot and don't have a clue what you're talking about." since high school, and I think they do not have place in discussion between two mature human beings.

I'll control myself when jerks stop making senseless attacks whenever I post.

So you think it's fine that zak can call for a vote to remove another member from the forum and call posts referencing an established open source project spam?

It pisses me off when whiners that contribute nothing post crap about others that are making a difference.

Charles Pegge

08-07-2010, 11:56

I would like to see thinBasic able to read C headers directly (as well as its own Basic headers). Then it would be possible to use many more libraries out there with minimal customisation. Think of the hours of maintenance work you would save - always having the latest headers for OpenGL or OpenCL.
:)

Yesterday I got Oxygen successfully reading gl.h glu.h and even the ugliest typedefs in glext.h. Once the parsing model is perfected, I hope Eros might be able to adopt it for thinCore.

Charles

Lionheart008

08-07-2010, 12:07

1) hi all, I would like to see more access and possibilities to the original "win api" sdk window frame and to build even without "oxygen" power ;). Just an idea.

see this topic from formerly days:
http://community.thinbasic.com/index.php?topic=3128.0

my win sdk example I add here again:

' Empty GUI script created on 07-08-2010 11:54:30 by (ThinAIR)

' Empty GUI script created on 01-16-2010 15:18:58 by frank (ThinAIR)
'--------------thinbasic sdk window like petzold did it ;)
'---------------------------------------------------------------------

Uses "console", "ui"

%CS_HREDRAW = 1001
%CS_VREDRAW = 1002
'%IDC_ARROW = 32512
'%IDI_APPLICATION = 32512
%TRANSPARENT = 1006
'%WHITE_BRUSH = 1003

Type SECURITY_ATTRIBUTES
nLength As DWord
lpSecurityDescriptor As Long
bInheritHandle As Long
End Type

Type POINTS
x As Integer
y As Integer
End Type

Type tagMSG
hwnd As DWord
message As DWord
wParam As Long
lParam As Long
time As DWord
pt As POINTAPI
End Type

Type WNDCLASSEX
cbSize As DWord
STYLE As DWord
lpfnWndProc As Long
cbClsExtra As Long
cbWndExtra As Long
hInstance As DWord
hIcon As DWord
hCursor As DWord
hbrBackground As DWord
lpszMenuName As Asciiz Ptr
lpszClassName As Asciiz Ptr
hIconSm As DWord
End Type

Type WNDCLASS
STYLE As DWord
lpfnwndproc As DWord
cbClsextra As Long
cbWndExtra As Long
hInstance As DWord
hIcon As DWord
hCursor As DWord
hbrBackground As DWord
lpszMenuName As Asciiz Ptr
lpszClassName As Asciiz Ptr
End Type

Type RECT
nLeft As Long
nTop As Long
nRight As Long
nBottom As Long
End Type

Declare Function FillRect Lib "USER32.DLL" Alias "FillRect" (ByVal hDC As DWord, lpRect As RECT, ByVal hBrush As DWord) As Long
Declare Function CreateWindowStation Lib "USER32.DLL" Alias "CreateWindowStationA" (lpszwinsta As Asciiz, ByVal dwReserved As DWord, ByVal dwDesiredAccess As DWord, lpsa As SECURITY_ATTRIBUTES) As DWord
Declare Function CreateWindowEx Lib "USER32.DLL" Alias "CreateWindowExA" (ByVal dwExStyle As DWord, lpClassName As Asciiz, lpWindowName As Asciiz, ByVal dwStyle As DWord, ByVal x As Long, ByVal y As Long, _
ByVal nWidth As Long, ByVal nHeight As Long, ByVal hWndParent As DWord, ByVal hMenu As DWord, ByVal hInstance As DWord, lpParam As Any) As DWord
Declare Function SetRect Lib "USER32.DLL" Alias "SetRect" (lpRect As RECT, ByVal X1 As Long, ByVal Y1 As Long, ByVal X2 As Long, ByVal Y2 As Long) As Long
Declare Function CreateSolidBrush Lib "GDI32.DLL" Alias "CreateSolidBrush" (ByVal crColor As DWord) As DWord
Declare Function DeleteObject Lib "GDI32.DLL" Alias "DeleteObject" (ByVal hObject As DWord) As Long
Declare Function BeginPaint Lib "USER32.DLL" Alias "BeginPaint" (ByVal hWnd As DWord, lpPaint As PAINTSTRUCT) As Long
Declare Function SetBkMode Lib "GDI32.DLL" Alias "SetBkMode" (ByVal hdc As DWord, ByVal nBkMode As Long) As Long
Declare Function SetTextColor Lib "GDI32.DLL" Alias "SetTextColor" (ByVal hdc As DWord, ByVal crColor As DWord) As DWord
Declare Function DrawText Lib "USER32.DLL" Alias "DrawTextA" (ByVal hDC As DWord, lpStr As Asciiz, ByVal nCount As Long, lpRect As RECT, ByVal uFormat As DWord) As Long
Declare Function EndPaint Lib "USER32.DLL" Alias "EndPaint" (ByVal hWnd As DWord, lpPaint As PAINTSTRUCT) As Long
Declare Sub PostQuitMessage Lib "USER32.DLL" Alias "PostQuitMessage" (ByVal nExitCode As Long)
Declare Function DefWindowProc Lib "USER32.DLL" Alias "DefWindowProcA" (ByVal hWnd As DWord, ByVal uMsg As DWord, ByVal wParam As DWord, ByVal lParam As Long) As Long
Declare Function LoadIcon Lib "USER32.DLL" Alias "LoadIconA" (ByVal hInstance As DWord, lpIconName As Asciiz) As DWord
Declare Function LoadBitmap Lib "USER32.DLL" Alias "LoadBitmapA" (ByVal hInstance As DWord, lpBitmapName As Asciiz) As DWord
Declare Function LoadCursor Lib "USER32.DLL" Alias "LoadCursorA" (ByVal hInstance As DWord, lpCursorName As Asciiz) As DWord
Declare Function RegisterClass Lib "USER32.DLL" Alias "RegisterClassA" (pcWndClass As WNDCLASS) As Word
Declare Function RegisterClassEx Lib "USER32.DLL" Alias "RegisterClassExA" (pcWndClassEx As WNDCLASSEX) As Word

Declare Function CreateWindow Lib "USER32.DLL" Alias "CreateWindowA" (lpClassName As Asciiz, lpWindowName As Asciiz, ByVal dwStyle As DWord, ByVal xx As Long, ByVal yy As Long, ByVal nWidth As Long, _
ByVal nHeight As Long, ByVal hwndParent As DWord, ByVal hMenu As DWord, ByVal hInstance As DWord, ByVal lpParam As DWord) As Long
Declare Function ShowWindow Lib "USER32.DLL" Alias "ShowWindow" (ByVal hWnd As DWord, ByVal nCmdShow As Long) As Long
Declare Function UpdateWindow Lib "USER32.DLL" Alias "UpdateWindow" (ByVal hWnd As DWord) As Long
'Declare Function GetMessage Lib "USER32.DLL" Alias "GetMessageA" (byval lpMsg As tagMSG, ByVal hWnd As DWord, ByVal uMsgFilterMin As DWord, ByVal uMsgFilterMax As DWord) As Long
Declare Function TranslateMessage Lib "USER32.DLL" Alias "TranslateMessage" (lpMsg As tagMSG) As Long
Declare Function DispatchMessage Lib "USER32.DLL" Alias "DispatchMessageA" (lpMsg As tagMSG) As Long
Declare Function GetClientRect Lib "USER32.DLL" Alias "GetClientRect" (ByVal hwnd As DWord, lpRect As RECT) As Long
Declare Function WindowFromDC Lib "USER32.DLL" Alias "WindowFromDC" (ByVal hDC As DWord) As Long

'==============================================================================
Function TBMain()
'------------------------------------------------------------------------------
' Program entry point
'--------------------------------------------------------------------------
Local hDlg As DWord

Dialog New 0, "Hello my dear SDK Window",-1,-1, 540, 380, _
%WS_POPUP Or _
%WS_VISIBLE Or _
%WS_CLIPCHILDREN Or _
%WS_CAPTION Or _
%WS_SYSMENU Or _
%WS_MINIMIZEBOX, _
0 To hDlg

Dialog Show Modal hDlg Call cbDlgProc

End Function

'==============================================================================
Sub DrawGradient (ByVal hDC As DWord)
'------------------------------------------------------------------------------
' Custom draw procedure for gradiend fill
'--------------------------------------------------------------------------

Local rectFill As RECT
Local rectClient As RECT
Local fStep As Single
Local hBrush As DWord
Local lOnBand As Long

GetClientRect(WindowFromDC(hDC), rectClient)
fStep = rectClient.nbottom / 200

For lOnBand = 0 To 199
SetRect(rectFill, 0, lOnBand * fStep, rectClient.nright + 1, (lOnBand + 1) * fStep)
hBrush = CreateSolidBrush(Rgb(100, 0, 255 - lOnBand))
Fillrect(hDC, rectFill, hBrush)
DeleteObject(hBrush)
Next

End Sub

'==============================================================================
CallBack Function cbDlgProc () As Long
'------------------------------------------------------------------------------
' WndProc is the message handler for all windows creating using the HelloWin
' class name. A single WndProc procedure can handle multiple windows by
' testing the hWnd variable passed to it.
'--------------------------------------------------------------------------

Local hDC As DWord
Local pPaint As PAINTSTRUCT
Local tRect As RECT

' The SELECT CASE is used to catch only those messages which the message
' handler needs to process. All other messages are passed through the
' tests to the default handler.
Select Case CBMSG

Case %WM_INITDIALOG

Case %WM_PAINT
hDC = BeginPaint(CBHNDL, pPaint)
GetClientRect(CBHNDL, tRect)
SetBkMode(hDC, %TRANSPARENT)
SetTextColor(hDC, %YELLOW)
DrawText(hDC, "Hello, my dear SDK Window!", -1, tRect, %DT_SINGLELINE Or %DT_CENTER Or %DT_VCENTER)
EndPaint(CBHNDL, pPaint)
Function = 1
Exit Function

Case %WM_ERASEBKGND
hDC = CBWPARAM
DrawGradient(hDC) ' Pass the DC of the region to repaint
Function = 1
Exit Function

Case %WM_CLOSE
Exit Function

End Select

End Function

if "codeptr" (to pass the address of a SUB or FUNCTION to Windows for callbacks) is possible for the future this win sdk frame should be realized too. great ;)

wce.lpfnWndProc = CODEPTR(WndProc)

2) thanks eros for his making open mind to thinbasic 2.x version.

3) do me a favour john: use your unfriendly words better at home, not here at the board, that's "kindergarten"-a-like and not very professional. If you like to say more about scriptbasic, use a own forum here at the board where you can do show your ideas or critics or making advertising for your language or other things. but try to use constructive critics without hurting or blaming persons or dumping down programming language reputations as you can imagine they are all hard working and engaged people here. don't forget: this board is a friendly board and should be have an positively idol effect for other users and thinbasic newbies.

It pisses me off when whiners that contribute nothing post crap about others that are making a difference.

If I were a teacher of your class you have to go out for next hours to calm down your mind with sports and running 10 kilometres around the block.

best regards, frank

Petr Schreiber

08-07-2010, 13:41

ErosOlmi

08-07-2010, 20:19

Eros,
Before you invest anymore time into thinBASIC you need to ask yourself who is the audience.

Hobby / newbie programmers
Commercial software developers
Your friends that think you're a great guy and it's cool that an Basic interpreter could be made with PB
Don't really care, thinBASIC was a personal endeavor and if others find it useful, all the better

I have no idea what the size of your user base is, do you know?

Are you happy being a Windows only Basic?

What would you do if Bob was hit bus or choked on a doughnut and PB closed the doors tomorrow?

The way I see it, you painted yourself into a corner with PB.

John

I do not need to ask any question to myself because I program thinBasic for passion. I do not need any money (I've a real life work that pays all the bills and much more), I do not like any compliment, I do not need and like any glory, I do not want to leave any sign of me other than looking my son becoming a good independent man.
It is just pure passion to build something with my hands and my brain. Can you understand that? I know, it's not that easy to get it because it seems too simple but it's the truth.

Even if only one programmer (me included) would like to use thinBasic I will be happy. Hopefuly it seems there are more people than just me. And that's enough.

But there is something I want and pretend: honesty, passion and good feeling. And of course a little more time, but this is impossible: time is the only thing I cannot buy.

I think you have a nice and talented brain but very often (really very often) I do not understand the way you use it.
The way you behave in some forums I frequented, the kind of messages you leave here and there do not make justice of your talent and knowledge.

Stop to insist always on the same things: Windows world is "only" 90% of the entire possible IT world (http://www.w3schools.com/browsers/browsers_os.asp). What can I ask more?

Ciao
Eros

MikeStefanik

08-07-2010, 22:09

I think the idea of being able to parse C header files is a good one, it would certainly save folks a lot of time when incorporating other libraries into their projects. COM integration, some basic OOP functionality and native 64-bit support are the other things that I think would be most useful. There's also some things which I think would be cool to add, like support for anonymous functions, named parameters, implicit dereferences through function pointers, implicit line continuation ... certainly there would be no shortage of things to work on.

Charles Pegge

08-07-2010, 23:02

Charles Pegge

09-07-2010, 01:59

Line Continuations

Demo

http://msdn.microsoft.com/en-us/vbasic/ee681551.aspx

John Spikowski

09-07-2010, 03:39

I do not need to ask any question to myself because I program thinBasic for passion. I do not need any money (I've a real life work that pays all the bills and much more), I do not like any compliment, I do not need and like any glory, I do not want to leave any sign of me other than looking my son becoming a good independent man.
It is just pure passion to build something with my hands and my brain. Can you understand that? I know, it's not that easy to get it because it seems too simple but it's the truth.

Even if only one programmer (me included) would like to use thinBasic I will be happy. Hopefuly it seems there are more people than just me. And that's enough.

But there is something I want and pretend: honesty, passion and good feeling. And of course a little more time, but this is impossible: time is the only thing I cannot buy.

Don't really care, thinBASIC was a personal endeavor and if others find it useful, all the better

Thanks for answering my question who your intended audience is.

I think you have a nice and talented brain but very often (really very often) I do not understand the way you use it.
The way you behave in some forums I frequented, the kind of messages you leave here and there do not make justice of your talent and knowledge.

If thinBASIC users don't like the board puluted with non-thinBASIC topics then I suggest you get rid of all non-thinBASIC boards. I'm not starting these battles and only defending myself from those trying to give me a hard time.

Stop to insist always on the same things: Windows world is "only" 90% of the entire possible IT world (http://www.w3schools.com/browsers/browsers_os.asp). What can I ask more?

Eros,

It was you that opened the door to looking beyond PowerBASIC. You could have saved yourself and everyone else a lot of time if your topic would have centered around PB 9 and asking the group what additional features they would like to see using the updated compiler features.

Saying your willing to entertain other compilers and OS's was misleading and generating false hope. I think it's great that your doing this for you as a personal challenge and learning experience.

John

John Spikowski

09-07-2010, 05:46

Named Parameters:

Proposing an implementation in Basic syntax:

function f( byval a=20 as long, byval b=21 as long ) as long
function=a+b
end function

Calling the function:

c=f( b=4 )

a is unspecified so its default value of 20 is used

Result: c=24

BCX handles it this way if I'm understanding what you're proposing.

FUNCTION TIMEVALUE% OPTIONAL(year%=1970, month%=1, day%=1, hour%=0, minutes%=0, seconds%=0)

MikeStefanik

09-07-2010, 05:54

For named parameters, and ease-of-parsing, you may want to consider handling it in the same way that Visual Basic does, which is the ":=" assignment operator. So, using Charles' example, it would look like:

c = f( b:= 4)

But it's not just used in the context of optional parameters, you can also completely reorder them, so that this code would be valid:

c = f( b:=4, a:=15 )

Obviously it's not a significant advantage when you're dealing with simple examples like this, but it comes in pretty handy when you're working with complex COM interfaces that have methods with 10 arguments. It enables you to pick and choose what parameters you want to pass in, and do it in a way that makes your code more readable.

ErosOlmi

09-07-2010, 07:16

John Spikowski

09-07-2010, 07:18

I happen to like the way ScriptBasic handles optional parameters.

FUNCTION Test(a, b)
IF a = undef THEN a = 1
IF b = undef THEN b = 2

' more code

Test = a + b
END FUNCTION

PRINT Test()

Would return 3

Charles Pegge

09-07-2010, 08:56

can you send me via mail (support at thinbasic.com) those .h files?

Thanks
Eros

Hi Eros,

I have posted them to SVN in the folder OxyReadHfile along with the latest Oxygen.

gl.h & glu.h come from Windows SDK (actually the 64 bit version but it does not matter)

the others come from Khronos: http://www.opengl.org/registry/

and I am still using thinBasic_wgl.inc - no problem mixing headers :)

Charles

ErosOlmi

09-07-2010, 10:05

Thanks Charles

Charles Pegge

09-07-2010, 10:21

Assignment vs Equality Operators

One of Basic's weaknesses is conflating the assignment operator with the equality operator. As Mike suggests using := to indicate assignment in Named Parameters (as in Visual Basic).

It might be useful to support the following operators:

== unambiguous equality operator
:= unambiguous assignment operator (with equality effect)

And if you wanted to both assign and test for equality as is often seen in COM programming:

if hresult := QueryInterface(guid,obj) then
if hresult ==E_ACCESSDENIED then
...
end if
end if

Charles

John Spikowski

09-07-2010, 11:05

Charles,

Here is another way to look at Assignment & Equality.

REF customer = addr
REF customer = phone
REF customer = bal

customer{"id"} = 1

addr{"name"} = "John Doe"
addr{"street"} = "Main St."
addr{"city"} = "Anytown"
addr{"state"} = "Unknown"

phone{"work"} = "800-555-1234"
phone{"home"} = "888-4444"

bal[30] = 100
bal[60] = 250
bal[90] = 0

PRINT customer{"id"},"\n"
PRINT customer{"name"},"\n"
PRINT customer{"street"},"\n"
PRINT customer{"city"},"\n"
PRINT customer{"state"},"\n"
PRINT customer{"work"},"\n"
PRINT customer{"home"},"\n"
PRINT customer[30],"\n"
PRINT customer[60],"\n"
PRINT customer[90],"\n"

C:\scriptbasic\test>reftest
1
John Doe
Main St.
Anytown
Unknown
800-555-1234
888-4444
100
250
0

Using this mechanisms the programmer can build up arbitrary complex memory structures without caring such complex things as pointers for example in C.

Charles Pegge

09-07-2010, 12:22

That looks a little complicated John but I can see why you need it in a typeless system where you don't have fixed data structures and pointers.

The concept of ref is useful, being synonymous with varptr() in Basic and '&' in C.

I use '&' in Oxygen, which is not entirely satisfactory since this symbol has 5 different meanings (at the last count!) according to context.

Perhaps a ref or addr prefix could be a useful alternative to VarPtr(), and make scripts a little clearer to read.

p=varptr(v)
p=&v
p=ref v
p=addr v
p=addressof v

which is the best?

To link or map one variable onto another:

dim as something a
dim as long byref b=ref a

b is now a dynamic variable linked to a

Charles

zlatkoAB

09-07-2010, 12:33

I vote for -
p=pointer(v)

Petr Schreiber

09-07-2010, 20:28

I am adding vote for "Implicit Line Continuations", that would be nice to have (although not critical).

I like the idea of named parameters, but I admit I never used them in languages that enabled them in the end.

The idea of := and == is quite interesting, and having them optional to remove ambiguity in some cases could be good.

Petr

Charles Pegge

10-07-2010, 11:20

Local Functions

This idea largely encompasses anonymous functions and lambda functions without the peculiar syntax.

It is simply the ability to create functions inside other functions, for local usage. They have their own local variables but share access to any parental static variables.

Trivial Example:

Function PrintTable(t,b,e)

Function PrintRow(t)
print t.col1 + tab + tab + t.col2 + tab + t.col3
End Function

for i=b to e
PrintRow(t(i) )
next

End Function

MikeStefanik

10-07-2010, 18:57

The specific benefit of anonymous functions is that you can use them inline for things like callback functions, and you concisely use closures and currying; of course, in the case of closures, you end up with some sticky problems unless the language inherently has object referencing and garbage collection because the anonymous function closes over its parent's local variables (in other words, it's not permissible to just destroy them when that function exits).

Edit: Just to clarify, an important aspect of this is that functions would become "first class citizens", intrinsic objects in the language where you could write code that looks something like this:

Function FooBar(ByVal x As Long, ByVal y As Long) As Function
Local z As Long

z = x * y;

Function = Function(ByVal a As Long) As Long
Function = (a * z) + 1
End Function
End Function

' Later, in some other code ...

Dim BarFoo As Function
Dim nResult As Long

BarFoo = FooBar(5, 10)
nResult = BarFoo(20) ' nResult is 1001

That's a very simple example of how a closure could be implemented. Note that the sticking point for a stack-oriented language is that when FooBar returns, it cannot destroy the variable 'z' because it must remain in the lexical scope of the anonymous function that's being returned. The memory allocated for it could only be released after any references to the closure are destroyed.

Charles Pegge

10-07-2010, 20:16

Mike,
That takes a lot of decyphering to get anywhere near understanding it. Do you have a more concrete example? Or do we call upon the assistance of an octopus.
:)

I get the idea that you can get functions to behave like variables and vice versa. But when it comes to applying this idea my mind goes blank!

Charles

MikeStefanik

10-07-2010, 21:46

I likely wouldn't make a good programming teacher, that's really the simplest way that I could think of demonstrating the idea. In actual programs, an example of where closures can be useful in simplifying code is with class factories, where you're dynamically creating an instance of a class; the implementation details of the actual class creation can be encapsulated in the outer function, and depending on the parameters, you get back a function that will return a reference to specific class instance that was created.

You can accomplish the same kinds of things without closures, but what a closure offers is encapsulation and the ability to maintain stateful information that would otherwise require that you use globals or statics. It's a useful concept, but it can be tough to initially wrap your head around if you've primarily worked with stack-based procedural languages. I threw it out there as an idea, but it would probably require a significant change in the core of how thinBasic works. Functions would need to be considered more as objects, not just addresses that you jump to and execute code.

Charles Pegge

10-07-2010, 22:53

MikeStefanik

11-07-2010, 00:04

This sounds like OOP with dynamic Objects plus the enhancement of returning function pointers as well as normal variables. You have complete control over the scope and lifespan of these entities. I can see the possibilities, but if it gets too complicated does that not defeat the purpose of making programs easier to maintain?

I think the answer to that really depends on the context of "complicated". These constructs can significantly simplify coding and make it easier to maintain if they're used appropriately (for example, any code that encapsulates information is going to be inherently easier to maintain and extend than corresponding code that uses loosely-coupled functions and globals). However, if you're talking about the implementation -- that is, how complicated would it be to incorporate these kinds of features in the language, then that's a whole other issue. Implementing all of them would essentially involve a shift of thinBasic to a fully object oriented language.

Edit: By the way, you made me think that another interesting idea would be support for dynamic scoping. By way of an example, what you have now is lexical scoping, such as:

GLOBAL X AS LONG

FUNCTION BarFoo() AS LONG
PRINT "BarFoo: the value of X is " + STR$(X)
END FUNCTION

FUNCTION FooBar() AS LONG
LOCAL X AS LONG

X = 10
PRINT "FooBar: the value of X is " + STR$(X)

X = 20
BarFoo()
END FUNCTION

FUNCTION PBMAIN () AS LONG
X = 5
FooBar()

WAITKEY$
END FUNCTION

If you run that program, you would get:

FooBar: the value of X is 10
BarFoo: the value of X is 5

However, if dynamic scoping was used, you'd get this output instead:

FooBar: the value of X is 10
BarFoo: the value of X is 20

Obviously you'd want to keep lexical scoping as the default for compatibility, but supporting dynamic scoping (either as a project option or as a qualifier when the variable is declared) could be interesting. For example, Perl supports this by allowing you declare variables using "my" (lexical) or "local" (dynamic) to specify scope.

Anyway, these are just ideas I'm throwing out there. Please understand that I'm not advocating any particular change to the language, I'm just brainstorming for fun.

John Spikowski

11-07-2010, 05:19

Charles Pegge

11-07-2010, 09:03

Mike,
I agree brainstorming is good fun and what this thread is for!

If I may attempt some simple definitions as I find the explanations on the web both awesome and awful!

Dynamic scoping: A function can see its caller's variables.

Closure: A function whose variables are determined by the caller

These closely related concepts are bad news for compilers but easy to implement in interpreters. I used to do a lot of dbaseIII programming and wrote a compatible interpreter adopting dynamic scoping.
This simplifies coding quite a lot since you don't have to worry about local/global scoping but if the program is complex, it can be hard to check.

How about:

Closure c()
local i
for i=b to e
f()
next
End Closure

Closure f()
print "Hello" ; i,
End Closure

b=1 : e=3

c()

Closure f()
print "GoodBye" ; i,
End Closure

c()

Result: Hello1 Hello2 Hello3 Goodbye1 Goodbye2 Goodbye3

John,
thinBasic can support callbacks - passing the address of a function as a parameter. As I understand it, this is confined to Windows Controls but it could be extended for general use.

There is also provision for calling by name where you use a string expression to determine the name of the function to be called. This string can of course be passed to another function. (A compiler cannot do this directly.)

Uses "console"

function Hello() as long
print "Hello! "
return 1
end function

function Goodbye() as long
print "Goodbye! "
return 1
end function

sub Many(n as long, fun as string)
dim as long i,a
for i=1 to n
call fun to a
next
function=1
end sub

Many(3,"Hello")
Many(3,"Goodbye")

Result: Hello! Hello! Hello! Goodbye! Goodbye! Goodbye!

Charles

John Spikowski

11-07-2010, 09:14

thinBasic can support callbacks

ICALL isn't a callback function in ScriptBasic. It's a way of dynamically calling functions indirectly. With ScriptBasic being typeless and forgiving with parameter passing, you can get pretty creative with code reuse.

Charles Pegge

11-07-2010, 09:35

I was using the term loosely. I understand your code demonstrates the ScriptBasic equivalent of a function pointer but with flexibility in parameter passing when the function is invoked.

Charles

MikeStefanik

11-07-2010, 16:24

A closure would be better defined as an outer function that returns an inner function (typically an anonymous function) where the outer function's local variables are preserved. It's called a closure because it "closes over" the lexical scope of the outer function's variables. If you wanted to use a different keyword to give the language a hint that a closure is being used, then a hypothetical syntax could be something like:

Closure MyOuterFunction(ByVal X As Long) ' Returns a function
Local Y As Long

Y = X * 10

Function MyInnerFunction(ByVal Z As Long) As Long
Function = Y + Z
End Function

Closure = MyInnerFunction
End Closure

Dim MyClosure As Closure
Dim MyResult As Long

' Call outer function which returns MyInnerFunction, creating the closure

MyClosure = MyOuterFunction(10)

' Call the inner function, which still has access to the local variables
' declared in MyOuterFunction, even though it has returned. The "Y" variable
' in MyOuterFunction has been "closed over"

MyResult = MyClosure(1) ' Result is 101

Hopefully that explains it a bit better.

John Spikowski

11-07-2010, 22:22

FYI

I want to make it perfectly clear that ScriptBasic is in no way in competition with thinBASIC as it's goals are much different. ScriptBasic is a typeless scripting language with a strong resemblance to traditional Basic and a sprinkle of Python and Perl added in for good measure. As with most scripting languages, getting the user code to work with as few framework requirements as possible and allowing to extend the language in a seamless way while running the same script on all platforms is the mission statement for ScriptBasic.

I post ScriptBasic examples here to show how a simplified approach to a requested feature may be addressed with thinBASIC. It is no different then Microsoft using VB to show how one of the other .NET base languages work in way everyone can understand. (Basic)

Charles Pegge

12-07-2010, 21:37

Mike,

Thanks for the clarification on closures. I think this would be quite difficult to implement though some thing to consider once thinBasic supports OOP.

It seems to me that once you have dynamic objects, these make perfect 'first class' entities - you can pass them around using their handles with ease and access their methods at any time to yield stateful information without special (and rather costly) scoping.

John,

I learned a lot from my brief encounter with scriptBasic. You have a huge range of modules there. You might be able to entice Peter Verhas to introduce some of these more recent programming paradigms into SB. Programming languages are so intricate to develop, the author has to be involved. If he still teaches, it would be a great project for his more advanced students.

http://peter.verhas.com/indexe.html

I found the entry in Wikibooks on OOP one of the clearest and most authoritative descriptions I've seen so far. I'ts an unfinished article though and comes to a grinding halt on the subject of closures :)

http://en.wikibooks.org/wiki/Object_Oriented_Programming

Charles

MikeStefanik

12-07-2010, 22:50

Thanks for the clarification on closures. I think this would be quite difficult to implement though some thing to consider once thinBasic supports OOP.

The concept of closures can seem pretty strange if you've never worked with them; I compare it to how people can struggle with the concept of pointers if they've never used a language that required them.

You're right, implementing closures in thinBasic would require some work. Most languages that support them (Java, C#, etc.) have garbage collection. As long as the reference to the closure exists, the local variables declared in the outer function would be "in use" and therefore couldn't be collected after the function exited.

Garbage collection itself is another interesting feature that could be added (independent of everything else we've discussed), but that too has it's own issues, particularly when interacting with native code that has no idea garbage collection is being used. You end up getting into issues like pinning and boxing so data can be safely used with non-GCed code, etc. etc.

John Spikowski

13-07-2010, 04:20

I learned a lot from my brief encounter with scriptBasic. You have a huge range of modules there. You might be able to entice Peter Verhas to introduce some of these more recent programming paradigms into SB. Programming languages are so intricate to develop, the author has to be involved. If he still teaches, it would be a great project for his more advanced students.

Armando Rivera is the lead developer for ScriptBasic now. Peter Verhas (author is acting as a mentor when needed) Everything I demonstrated here has been in ScriptBasic for ages. ScriptBasic has been production stable for almost 10 years and just keeps getting better. (new and updated extension modules)

I would love to see ScriptBasic being used as a way to teach programming. It's the 'Erector Set' of programming languages.

http://www.girdersandgears.com/sets/ampark-top.jpg

zak

13-07-2010, 09:06

ErosOlmi

13-07-2010, 09:57

suggestion for the innovative RawText
to make it possible to include a variable inside the RawText and by something like an escape char before and after it thinbasic will think that it is a variable and not a sequence of chars.

Dim mystr As String = "asd"
Dim s As String=RawText
"?"mystr"?"
End RawText
MsgBox 0,s

i want it do display asd, and not "?"mystr"?"

RAWTEXT/END RAWTEXT will get all what is inside its block and return as string.
What I can add is a substitution function able to get a string and substitute some mark with script variables.
I think I have already something ready for it.

Charles Pegge

13-07-2010, 11:36

This could be a little risky. The ideal of Rawtext is to have no symbolic markers inside at all so that any script can be safely supported. However the concept is a very useful one and well worth having in addition to Rawtext.

In Oxygen I borrowed an idea from DOS batch files, and built a simple macro system using the tokens %1 .. %9. These get substituted by the macro arguments.

Charles

ErosOlmi

13-07-2010, 12:01

I was thinking about a function like

EXPAND$(InString AS STRING)

able to substitute a tag variable name inside InString string

Dim MyLong as LONG
Sim MyString as string

MyLong = 123
MyString = "The value is $MyLong"
MyString = EXPAND$(MyString)
'---Result would be: "The Value is 123"

For example PHP uses $ sign

Charles Pegge

13-07-2010, 12:32

Yes that looks good Eros.

Extending this functionality a little further, would it be possible to insert strings into the script itself, therebye implementing macros?

You already support it for Call names

Charles

Petr Schreiber

14-07-2010, 12:13

Ad 2

Threads are very powerful, but bring many problems. I am recently working on multithreaded application in C# and it is pure hell. Problems with GUI, problems with OpenGL... phew!

I read that Python does not have true threads, that it only behaves like classic thread, but all running in one. When I saw this the first time, I thought the authors had to be crazy. But now I understand - this approach removes ton of problems.

So maybe good to have option whether to have true thread or "simulated" thread like in Python could lead to great flexibility.

Petr

Charles Pegge

14-07-2010, 14:02

If you have an hour to spare this video gives the inside track on threads and parallelism from the guy who develops the Windows Kernels.

http://channel9.msdn.com/shows/Going+Deep/Dave-Probert-Inside-Windows-7-User-Mode-Scheduler-UMS/

ErosOlmi

14-07-2010, 14:59

I already have an idea of how to develop threads in thinBasic but I need first to change internal Core structures. That's why I told that all Core SDK functions need to have one or two additional parameters.

thinBasic is not really a "standard" interpreter but instead a sort of continuous parser. Internally there is a kind "cursor" moving around, up and down in the source code.
Multiple threads would only means to have multiple "cursors" moving simultaneously over the source code instead of only one.
Of course there will be a new set of structures to govern priorities and setting semaphores but the whole idea is already in my mind.

zak

14-07-2010, 19:29

subject: more automatic functionality to X closebox

suppose a new user run this code:

Uses "UI","TBGL"

Global hWnd As DWord

FUNCTION TBMAIN()

' -- Create and show window
hWnd = TBGL_CreateWindowEx("testing x closeBox - press ESC to exit, do not click on X close box", 640, 480, 32, %TBGL_WS_WINDOWED Or %TBGL_WS_CLOSEBOX)
MsgBox 0,"DO Not click on X close Box"
TBGL_ShowWindow
' -- Resets status of all keys
TBGL_ResetKeyState()

While Timer
' -- ESCAPE key to exit application
If TBGL_GetWindowKeyState(hWnd, %VK_ESCAPE) Then Exit While

Wend

TBGL_DestroyWindow
END FUNCTION

he can press ESC to exit , but he forgot to add a code to capture clicking on X close box ; then the thinbasic process will continue to run in the background, if he tried more than once there will be an accumulation of thinbasic processes running in the background.
so is it possible for thinbasic internally to manage this situation?? ie to sense clicking on X then to close thinbasic and all what is neccessary to return the pc to a normal state as it was before .
thanks

Petr Schreiber

14-07-2010, 19:39

Hi Zak,

why do you use this?

While Timer

Wend

If I used it in some sample code I apologize, but that is not good approach.
If you use the following, recommended even by TBGL templates, then when user clicks close box, it correctly goes out of the loop:

While TBGL_IsWindow(hWnd)

Wend

Let me know.

Petr

zak

14-07-2010, 20:08

thank Petr
normally i use TBGL_IsWindow , but i mean a more aware X functionality for different situations, this is because my above code is disastrous to the cpu, . i remember reading that clicking on X while in loop can't destroy the process but i can't find.
regards

Petr Schreiber

14-07-2010, 20:22

Aha,

well, to not bake the CPU you can use TBGL_BindPeriodicFunction approach:

'
' The most basic skeleton for TBGL
' Petr Schreiber, started on 07-14-2010
'

Uses "TBGL"

Function TBMain()
Local hWnd As DWord
Local FrameRate As Double

' -- Create and show window
hWnd = TBGL_CreateWindowEx("TBGL script - press ESC to quit", 640, 480, 32, %TBGL_WS_WINDOWED Or %TBGL_WS_CLOSEBOX)
TBGL_ShowWindow

' -- Resets status of all keys
TBGL_ResetKeyState()

' -- We will set GameLoop function to be executed each 20ms
TBGL_BindPeriodicFunction( hWnd, "GameLoop", 20 )

' -- Once the command below is executed, further script execution
' -- is halted and only periodic calling of the bound function is performed
TBGL_ProcessPeriodicFunction(hWnd)

TBGL_DestroyWindow
End Function

Sub GameLoop()

Static rotation As Double
Static frameRate As Double
Static hWnd As Double = TBGL_CallingWindow

frameRate = TBGL_GetFrameRate
rotation += 45/FrameRate

TBGL_ClearFrame

TBGL_Camera 0, 0, 5, _
0, 0, 0

TBGL_Rotate rotation
TBGL_Box 1,1,1

TBGL_DrawFrame

If TBGL_GetWindowKeyState(hWnd, %VK_ESCAPE) Then
TBGL_UnBindPeriodicFunction(hWnd)
Exit Sub
End If

End Sub

Another option would be to add something like TBGL_AddEventHandler(%TBGL_OnClose, "FunctionHere") maybe?

I think it is not very common to end the application when user clicks X button, but I am curious what others think about it.

The situation like:

WHILE 1
WEND

is quite common, and TB has not much of chance to detect whether the interpreter ended in loop by design or accident.
Quite interesting problem.

Thanks,
Petr

zak

14-07-2010, 20:59

thanks Petr , i can say that there is no increase in my cpu temperature or fan speed running you code, yes if it is possible for the future 2.x thinbasic if it can detect some misusage regarding the exit situations. and to not allow unmanaged processes in memory, and may be give a warning during the parsing. may be some fuzzy logic ??.

ErosOlmi

20-08-2010, 10:57

Re-organized first post in this thread in order to add all the suggestions I was able to discover along the thread.
Hope to have got them all.

Also added one new request regarding managing thinBasic source code not only like plain text files bust also as XML file in order to be able to add to source file additional informations.

Development of thinBasic 2.x will start in few weeks (let's say from Nov2010) so there is plenty of time to add more ... requests.

Ciao
Eros

Petr Schreiber

20-08-2010, 11:29

Thanks for the info,

is there any difference between 4/ and 13/?

Petr

Michael Hartlef

20-08-2010, 13:46

One thing I would like to see is being able to change the icon of a bundled exe.

Michael Hartlef

20-08-2010, 13:50

Some more:

1) A Thinbasic exe should extract the bundled scripts into memory instead on the harddrive and read them from there
2) Being able to create a thinbasic script at runtime dynamically and let it run or use it as a function

ErosOlmi

20-08-2010, 14:29

is there any difference between 4/ and 13/?

No.

zak

20-08-2010, 16:50

my suggestion called BitMapInline ,it is just for fun, and can be useful if we do not want to attach a small picture together with the tbasic file.
this is like this:
1- thinbasic can convert small images (< 100 k) to a big string of characters,
2- now in the code we use that string inside the code whatever it is uglly and long it can be at the end of the code page, thinbasic then convert that string to the original picture and save it to a temporary file then loading it for usage.
this idea is from the module "win32 gui" for designing gui for perl on ms windows, the site of the author of the module here:
http://dada.perl.it/gui_docs/BitmapInline.html
http://search.cpan.org/~robertmay/Win32-GUI-1.06/Win32-GUI-BitmapInline/BitmapInline.pm
it show partially how it is used.
to give an idea how it is used , this is a complete program, it produces the attached picture
i have no idea how to convert a picture to a string an vice versa, may be every developer can have his own version.

#!perl -w
use strict;
use warnings;
use Win32::GUI();
use Win32::GUI::BitmapInline ();
my $mw = Win32::GUI::Window->new(
-title => "Icons",
-size => [120,180],
-pos => [200,200],
);
my $hIcon = CreateIcon();
$mw->AddLabel(
-icon => $hIcon,
-pos => [ 20, 20 ],
);
$mw->Show();
Win32::GUI::Dialog();
sub CreateIcon {
newIcon Win32::GUI::BitmapInline( q(
AAABAAEAEBAAAAEAAABoBAAAFgAAACgAAAAQAAAAIAAAAAEAIAAAAAAAQAQAAAAAAAAAAAAAAAAA
AAAAAAAAAAABAAAACQAAABMAAAAYAAAAGAAAABcAAAATAAAACwAAAAMAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAACwAAAC8AAABTAAAAXwAAAF8AAABeAAAAVgAAAEUAAAAtAAAAHAAAABsA
AAAhAAAAIwAAACIAAAAcAAAAD2YgAjeKLQyvfCsQzIMvG9ODLxvTZiIIzT0TAboAAACZAAAAggAA
AGgAAABnAAAAcwAAAHcAAAB2AAAAZwAAAD23PQ/F3VIz//ljUP/9cFv/82xS/9JuQf/4ZVH/zEop
+y0yB9cSVxLbIXkh6i2ELeshfiHsEWsR5wMwA8AAAABntz0Po/ljUP/9emL//oxu/9yFVv/1zZv/
73BS//1qV/+Shzz/U69P/2euXP9hymH/VcNV/zi1OP8WehbpAAAAZqEyAyPhXT/x/Yhr/+F9Uf/6
x5T//9Og/+V3UP/4dFv/kZxQ/4bCgP/v9eD/Va9V/3PSc/9SwlL/GHUY2QAAAD0AAAANVhsBYqFM
Qu9CI1r/QzZ4/2BId/+7Wzj7k3o1/4Lagv+kxpf///Xs/7rPqP9jwWP/QaNB+QApAHcAAAAXAAAA
SQQEBO0DBg3/Dytx/xQ6oP8QMZf/Ag9c7gAlAK9AkEDLQ4iO/xB2uf8gfbv/GnFb+wAbALQAAABX
AAAAEwoKCsoaGhr/Ei9o/xpNs/8dV73/G0+1/w0yk/8ACCCtBT1elC2T8v8zmf//M5n//yuR7/8E
LETMAAAAeQAAACUVFRX/KCgo/xhCgf8mc9n/JnPZ/yZz2f8bXL3/AA8ssx1zsNA/pf//QKb//0Cm
//8+pP//H3u+9wAAAJEAAAA3ICAg8TU1Nf8lRWv/MJD2/zSa//8zlvr/IXPS/wAWMa0rhsbWTLL/
/02z//9Ns///Sa///zGX5v8AChCdAAAAPRQUFKJKSkr/QkJC/zZGZf8bRZD/ImLG/xVHff8AGDGG
MpDNzkyy8v9KsOz/V73//1C2//9Cper/ACc7pgAAADAAAAARLi4u8Glpaf+NjY3/pKSk/09PT/8R
HSbXAAAALwtsnZcph7n/UqTS/2Go0/9Rn9D/GHWk/wAAAFoAAAAZAAAAAAAAACEsLCyyXFxc/0tL
S+QhISGuAAAAJwAAAAgAYJAiKYOz8IvE5f+hz+r/V6TP/w1eia0AAAAgAAAABgAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABjlCEugKqETJG1iQBWgV8AAAANAAAABAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAH8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA
AAD/gQAA//8AAA==
) );
}

kryton9

10-09-2010, 02:22

Well here is a very radical idea for thinBasic 2.x direction.

As you might know or not know, google has a very nice BASIC for Android. Unfortunately, development on it has not been updated. It is a great oop Basic waiting for someone with Eros's passion to take it over. They are looking for developers. This could be perhaps where Eros's passion and productivity could really take off on the future platform for most users. I know I have been saying this, but think about it. 2 years ago, most of us were on desktops. Now I am sure many are using notebooks or netbooks as much or more than desktops. Smartphones are used by my friends who are not computer freaks, they just use facebook, email and surf, their main devices now are smartphones. Tablets will be next. The future is small full day use portable devices with lots of power. I think the Eros, Charles, Petr, Mike could all add to this BASIC that needs attention.

I think with a nice foundation already there, no recoding of all that has been done is necessary. Just pick up with what is there and make it awesome as it deserves!

http://code.google.com/p/simple/

http://code.google.com/p/simple/wiki/ContributingToSimple

It has been a year since any updates, so I am sure this is ripe to take over and bring on the BASIC revolution to these devices!

fgasoi

07-07-2011, 17:00

If I could put in two cents on behalf of the audience of non-programmers. I am an electrical engineer who has spent the vast majority of his 40+ year career designing electronic hardware and managing hardware designers. I have never studied software design, and would not call myself even a casual programmer. Early on I used FORTRAN and BASIC, and when the need has arisen over the years I have gone back to BASIC, usually QUICKBASIC under DOS. After a gap of many years the need to do some programming returned, and QUICKBASIC was gone. I could not get my head around Visual Basic, found ThinBasic on a Google search, and fell in love.

For those of us in the audience who match my profile, I would beg you to retain the current functionality in v1.9 and if you choose to go the OOP route (which remains a total mystery to me), please restrict it to 2.x as a new branch. I think that there is more than enough functionality available now to meet the vast majority of the needs of people like me, and if there remained sufficient bandwidth to handle maintenance and the occasional upgrade request, that would be great. If the whole product changed into simply another language using objects and classes I would be lost.

I would also like to see this thread go back to what Eros originally requested - ideas and suggestions rather than detailed code examples and arguments (sometimes less than civil) about the relative merits of different development environments and compilers. Irrelevant to the present discussion.

One suggestion I would put forward is to have the bundle extract the dll's to disk the first time it is run and to leave them there. It would subsequently extract and start much faster, especially if the executable then extracted directly to memory as others have suggested. I would also vote for the ability to include custom icons - nice touch.

Finally, I would like to take the opportunity to issue an enormous thank you to Eros and to the others responsible for making ThinBasic available to users like me - a language of great power and elegance that is simple and accessible.

Rick

ErosOlmi

07-07-2011, 17:15

Thanks a lot Rick.

What I can say for sure is that whatever direction we will get, I will not break syntax compatibility with previous thinBasic version. All new features will not change anything in what is the current syntax.
In version 1.8.8.0 I started to add what we call "module classes" that will start a sort of OOP syntax (dotted notation) and not OOP language. Just syntax. But this will not break any current syntax.

Regarding Bundle Exe, that is an area in which I would like thinBasic to improve a lot.
Bundling area was in charge of another person. For those of you who followed thinbasic born, you may remember his name: Roberto Bianchi.
Roberto did a tremendous job but now that job seems having to reached its boundaries in terms of options and flexibility.
During summer I will work a lot on bundling exe trying to simplify it allowing more opportunities and functionalities.

Instead what will be stopped in version 2.x will be compatibility with old Windows versions.

Ciao
Eros

John Spikowski

07-07-2011, 21:20

If the interest is there, a thinBasic to OxygenBasic translator would be a great open source project. IMHO

Chris Boss

01-05-2012, 00:48

I need to spend some more time with thinbasic, but I do have some ideas to add to it.

I need to see if the module building feature will allow me to create a GUI engine module similiar to my EZGUI.

I was thinking of possibly porting over an early version of EZGUI (say 1.0, 2.0 or even maybe 3.0) to a thinbasic module, so building user interfaces would be easy even for novices.

Also I build Visual designers possibly if I could build an EZGUI module, then I could port over a visual designer so it could generate code for thinbasic using the module.

Just an idea !

Tell me if this is possible for a thinbasic module:

The ability to call a function which would be similiar to WinMain in PowerBasic and let a module take control. The function would be pased three code pointers which it would need to call when it requests the app to do something. In PowerBasic I simply call back to these subroutines in the app using CALL DWORD, but because thinbasic is a scripting language I would assume I can't call back to an actual subroutine like I do with PowerBasic. I would have to call a thinbasic internal routine which would in turn forward the call to the appropriate section of script, rather than machine code like with PowerBasic.

An EZGUI module would make thinbasic far more usable by novices, because it does not use any API functions or API constants at all.

To give you an idea of how EZGUI code normally looks, which is what a thinbasic EZGUI module would hopefulyl be able to support via thinbasic scripting, here is a simple example of all the code for a one form app with the different controls supported by EZGUI 3.0:

' *************************************************************************************
' Application Constants and Declares
' *************************************************************************************
' add any custom constants here
' add any custom declares here
DECLARE SUB Form1_Display(BYVAL Parent$)
DECLARE SUB Form1_Design()
DECLARE SUB Form1_Events(CID&, CMsg&, CVal&, Cancel&)
' ------------------------------------------------

' ----------------------------------------------------------
%FORM1_FILE = 4000
' ----------------------------------------------------------
%FORM1_NEWFILE = 4005
%FORM1_OPENFILE = 4010
%FORM1_SAVEFILE = 4015
%FORM1_SAVEAS = 4020
%FORM1_SEPARATOR_4025 = 4025
%FORM1_EXIT = 4030
' ----------------------------------------------------------
%FORM1_EDIT = 4100
' ----------------------------------------------------------
%FORM1_CUT = 4105
%FORM1_COPY = 4110
%FORM1_PASTE = 4115
' ----------------------------------------------------------
%FORM1_HELP = 4200
' ----------------------------------------------------------
%FORM1_HELP1 = 4205
%FORM1_BUTTON1 = 100
%FORM1_CHECK1 = 105
%FORM1_RADIO1 = 110
%FORM1_TEXT1 = 115
%FORM1_LISTBOX1 = 120
%FORM1_COMBOBOX1 = 125
%FORM1_VSCROLL1 = 130
%FORM1_HSCROLL1 = 135
%FORM1_LABEL1 = 140
%FORM1_PROGRESS1 = 145
%FORM1_UPDOWN1 = 150
%FORM1_RICHTEXTONE1 = 155
%FORM1_LISTVIEW1 = 160
%FORM1_TREEVIEW1 = 165
%FORM1_HTRACKBAR1 = 170
%FORM1_DATETIME1 = 175
%FORM1_FRAME1 = 180
%FORM1_TAB1 = 185
' ------------------------------------------------
DECLARE SUB FORM1_FILE_Select()
DECLARE SUB FORM1_NEWFILE_Select()
DECLARE SUB FORM1_OPENFILE_Select()
DECLARE SUB FORM1_SAVEFILE_Select()
DECLARE SUB FORM1_SAVEAS_Select()
DECLARE SUB FORM1_EXIT_Select()
DECLARE SUB FORM1_EDIT_Select()
DECLARE SUB FORM1_CUT_Select()
DECLARE SUB FORM1_COPY_Select()
DECLARE SUB FORM1_PASTE_Select()
DECLARE SUB FORM1_HELP_Select()
DECLARE SUB FORM1_HELP1_Select()
DECLARE SUB FORM1_BUTTON1_Click()
DECLARE SUB FORM1_CHECK1_Click()
DECLARE SUB FORM1_RADIO1_Click()
DECLARE SUB FORM1_TEXT1_Change()
DECLARE SUB FORM1_LISTBOX1_Change(BYVAL CVal&)
DECLARE SUB FORM1_COMBOBOX1_Change(BYVAL CVal&)
DECLARE SUB FORM1_VSCROLL1_Change(BYVAL CVal&)
DECLARE SUB FORM1_HSCROLL1_Change(BYVAL CVal&)
DECLARE SUB FORM1_UPDOWN1_Change(BYVAL CVal&)
DECLARE SUB FORM1_RICHTEXTONE1_Load(BYVAL Mode&, BYVAL D$)
DECLARE SUB FORM1_RICHTEXTONE1_Change()
DECLARE SUB FORM1_LISTVIEW1_Fill(BYVAL Mode&)
DECLARE SUB FORM1_LISTVIEW1_Change(BYVAL CVal&)
DECLARE SUB FORM1_LISTVIEW1_Select(BYVAL CVal&)
DECLARE SUB FORM1_TREEVIEW1_Fill(BYVAL Mode&)
DECLARE SUB FORM1_TREEVIEW1_Select(BYVAL CVal&)
DECLARE SUB FORM1_HTRACKBAR1_Change(BYVAL CVal&)
DECLARE SUB FORM1_DATETIME1_Change()
DECLARE SUB FORM1_TAB1_Change(BYVAL CVal&)

' *************************************************************************************
' Application Global Variables and Types
' *************************************************************************************
' add any globals here
' Global Handles for menus
GLOBAL FORM1_hMenu0&
GLOBAL FORM1_hMenu1&
GLOBAL FORM1_hMenu2&
GLOBAL FORM1_hMenu3&

' Note: Do NOT change the names of the EZGUI Callback Procedures !
' --------------------
#INCLUDE "C:\ezgui30\includes\ezwmain.inc" ' EZGUI Include file for WinMain
' --------------------
' *************************************************************************************
' EZGUI Program Control Functions
' *************************************************************************************
SUB EZ_Main(VerNum&)
' VerNum& = Version number (ie. 101 = Version 1.01)
EZ_Reg 0, 0 ' use your Customer ID Number and Registration Number here.
EZ_DefFont 6, "Arial", 10, "V"
EZ_DefFont 7, "Courier New", 10, "F"
EZ_DefFont 8, "Times New Roman", 10, "V"
EZ_DefFont 9, "Modern", 10, "V"
Form1_Display ""
END SUB
' -------------------------------------------------------------------------------------
SUB EZ_DesignWindow(FormName$)
' - NOTE: EZGUI passes back Form Name in uppercase letters
SELECT CASE FormName$
CASE "FORM1"
Form1_Design
CASE "{ABORT}"
' add controls to Print Abort Dialog here
CASE ELSE
END SELECT
END SUB
' -------------------------------------------------------------------------------------
SUB EZ_Events(FormName$, CID&, CMsg&, CVal&, Cancel&)
' =============================================================================
' CID& = Control ID or %EZ_Window (0) if Window event
' CMsg& = Control Event Message (Type)
' CVal& = Value: (ie. Scrollbar value)
' Cancel& = is for Closing a Window. Set Cancel& to -1 (True) to stop close
' =============================================================================
' - NOTE: EZGUI passes back Form Name in uppercase letters
' =============================================================================
' - NOTE: EZGUI passes back Form Name in uppercase letters
SELECT CASE FormName$
CASE "FORM1"
Form1_Events CID&, CMsg&, CVal&, Cancel&
CASE "{ABORT}"
CASE "{APP}"
IF CMsg&=%EZ_Terminate THEN
END IF
CASE ELSE
END SELECT
END SUB
' -------------------------------------------------------------------------------------

' add any Library procedures/functions here

' *************************************************************************************
' Put Your Code Here
' *************************************************************************************
SUB Form1_Display(BYVAL Parent$)
FORM1_hMenu0&=EZ_DefMainMenu( %FORM1_FILE, "&File", "")
EZ_Color -1, -1
EZ_Form "FORM1", Parent$, "Your Dialog", 0, 0, 122, 30, "CK"
END SUB
' ------------------------------------------------
GLOBAL Form1_FF&
SUB Form1_Design()
LOCAL FF&
'---------------------------------------------------------------
FF& = 9 ' - Offset for Font Numbers
Form1_FF& = FF& ' Global for ODButtons Draw code
'---------------------------------------------------------------
EZ_AddMenuItem FORM1_hMenu0&, %FORM1_EDIT, 0, "&Edit", ""
EZ_AddMenuItem FORM1_hMenu0&, %FORM1_HELP, 0, "&Help", ""
FORM1_hMenu1&=EZ_DefSubMenu( %FORM1_NEWFILE, "&New File", "")
EZ_SetSubMenu FORM1_hMenu0& , %FORM1_FILE, FORM1_hMenu1&
EZ_AddMenuItem FORM1_hMenu1&, %FORM1_OPENFILE, 0, "&Open File", ""
EZ_AddMenuItem FORM1_hMenu1&, %FORM1_SAVEFILE, 0, "&Save File", ""
EZ_AddMenuItem FORM1_hMenu1&, %FORM1_SAVEAS, 0, "Save File &As", ""
EZ_AddMenuItem FORM1_hMenu1&, %FORM1_SEPARATOR_4025, 0, "-", ""
EZ_AddMenuItem FORM1_hMenu1&, %FORM1_EXIT, 0, "E&xit", ""
FORM1_hMenu2&=EZ_DefSubMenu( %FORM1_CUT, "Cu&t", "")
EZ_SetSubMenu FORM1_hMenu0& , %FORM1_EDIT, FORM1_hMenu2&
EZ_AddMenuItem FORM1_hMenu2&, %FORM1_COPY, 0, "&Copy", ""
EZ_AddMenuItem FORM1_hMenu2&, %FORM1_PASTE, 0, "&Paste", ""
FORM1_hMenu3&=EZ_DefSubMenu( %FORM1_HELP1, "&Contents", "")
EZ_SetSubMenu FORM1_hMenu0& , %FORM1_HELP, FORM1_hMenu3&
' ------------------------------------------------
EZ_Color-1,-1
EZ_UseFont -1
EZ_UseFont 4
EZ_Button %FORM1_BUTTON1, 4, 1, 13, 3, "Button 1", "T"
' --------------------------------------------------------------
EZ_UseFont 4
EZ_CheckBox %FORM1_CHECK1, 25, 1, 17, 2, "Check 1", "T"
' --------------------------------------------------------------
EZ_UseFont 4
EZ_Radio %FORM1_RADIO1, 42, 1, 17, 2, "Radio 1", "T"
' --------------------------------------------------------------
EZ_Color 1, 25
EZ_UseFont 4
EZ_Text %FORM1_TEXT1, 5, 5, 15, 2, "", "EST"
' --------------------------------------------------------------
EZ_Color-1,-1
EZ_UseFont 4
EZ_ListBox %FORM1_LISTBOX1, 4, 8, 14, 4, "Item 1|Item 2|Item 3|Item 4|Item 5|", "SAVT"
' --------------------------------------------------------------
EZ_UseFont 4
EZ_ComboBox %FORM1_COMBOBOX1, 4, 13, 16, 5.25, "Item 1|Item 2|Item 3|Item 4|Item 5|", "SAVT"
EZ_SelectItem "Form1", %FORM1_COMBOBOX1, 0
' --------------------------------------------------------------
EZ_UseFont 4
EZ_VScroll %FORM1_VSCROLL1, 4, 16, 3, 7, ""
EZ_SetVScroll "Form1", %FORM1_VSCROLL1, 0, 100, 50, 1
' --------------------------------------------------------------
EZ_UseFont 4
EZ_HScroll %FORM1_HSCROLL1, 4, 24, 18, 2, ""
EZ_SetHScroll "Form1", %FORM1_HSCROLL1, 0, 100, 50, 1
' --------------------------------------------------------------
EZ_Color 9, 15
EZ_UseFont 4
EZ_Label %FORM1_LABEL1, 11, 16, 14, 2, "Label 1", "C"
' --------------------------------------------------------------
EZ_Color-1,-1
EZ_UseFont 4
EZ_ProgressBar %FORM1_PROGRESS1, 30, 21, 20, 2, ""
EZ_SetPBar "Form1", %FORM1_PROGRESS1, 0, 100, 50
' --------------------------------------------------------------
EZ_UseFont 4
EZ_UpDown %FORM1_UPDOWN1, 31, 24, 2.375, 2, ""
EZ_SetUpDown "Form1", %FORM1_UPDOWN1, 0, 100, 50
' --------------------------------------------------------------
EZ_UseFont 4
EZ_RichText1 %FORM1_RICHTEXTONE1, 59, 4, 24, 5, "STVB"
FORM1_RICHTEXTONE1_Load -1, ""
' --------------------------------------------------------------
EZ_UseFont 4
EZ_ListView %FORM1_LISTVIEW1, 59, 11, 27, 5, "Column 1{15}|Column 2{15}{C}|Column 3{15}{R}|", "SVT"
FORM1_LISTVIEW1_Fill -1
' --------------------------------------------------------------
EZ_UseFont 4
EZ_TreeView %FORM1_TREEVIEW1, 61, 17, 28, 5, "SVT+-"
FORM1_TREEVIEW1_Fill -1
' --------------------------------------------------------------
EZ_UseFont 4
EZ_HTrackBar %FORM1_HTRACKBAR1, 43, 24, 27, 2, ""
EZ_SetTBar "Form1", %FORM1_HTRACKBAR1, 0, 100, 50
' --------------------------------------------------------------
EZ_UseFont 4
EZ_DateTime %FORM1_DATETIME1, 91, 3, 19, 2, "T"
' --------------------------------------------------------------
EZ_UseFont 4
EZ_Frame %FORM1_FRAME1, 29, 7, 11, 5, "Frame 1", ""
' --------------------------------------------------------------
EZ_UseFont 4
EZ_TabControl %FORM1_TAB1, 30, 14, 21, 6, "Tab 1|Tab 2|Tab 3", ""
' --------------------------------------------------------------
END SUB
' ------------------------------------------------
SUB Form1_Events(CID&, CMsg&, CVal&, Cancel&)
SELECT CASE CID&
CASE %EZ_Window
IF CMsg&=%EZ_Close THEN
END IF
CASE %FORM1_FILE
FORM1_FILE_Select
CASE %FORM1_NEWFILE
FORM1_NEWFILE_Select
CASE %FORM1_OPENFILE
FORM1_OPENFILE_Select
CASE %FORM1_SAVEFILE
FORM1_SAVEFILE_Select
CASE %FORM1_SAVEAS
FORM1_SAVEAS_Select
CASE %FORM1_SEPARATOR_4025
CASE %FORM1_EXIT
FORM1_EXIT_Select
CASE %FORM1_EDIT
FORM1_EDIT_Select
CASE %FORM1_CUT
FORM1_CUT_Select
CASE %FORM1_COPY
FORM1_COPY_Select
CASE %FORM1_PASTE
FORM1_PASTE_Select
CASE %FORM1_HELP
FORM1_HELP_Select
CASE %FORM1_HELP1
FORM1_HELP1_Select
CASE %FORM1_BUTTON1
IF CMsg&=%EZ_Click THEN
FORM1_BUTTON1_Click
END IF
CASE %FORM1_CHECK1
IF CMsg&=%EZ_Click THEN
FORM1_CHECK1_Click
END IF
CASE %FORM1_RADIO1
IF CMsg&=%EZ_Click THEN
FORM1_RADIO1_Click
END IF
CASE %FORM1_TEXT1
IF CMsg&=%EZ_Change THEN
FORM1_TEXT1_Change
END IF
CASE %FORM1_LISTBOX1
IF CMsg&=%EZ_Change THEN
FORM1_LISTBOX1_Change CVal&
END IF
CASE %FORM1_COMBOBOX1
IF CMsg&=%EZ_Change THEN
FORM1_COMBOBOX1_Change CVal&
END IF
CASE %FORM1_VSCROLL1
IF CMsg&=%EZ_Change THEN
FORM1_VSCROLL1_Change CVal&
END IF
CASE %FORM1_HSCROLL1
IF CMsg&=%EZ_Change THEN
FORM1_HSCROLL1_Change CVal&
END IF
CASE %FORM1_UPDOWN1
IF CMsg&=%EZ_Change THEN
FORM1_UPDOWN1_Change CVal&
END IF
CASE %FORM1_RICHTEXTONE1
IF CMsg&=%EZ_Change THEN
FORM1_RICHTEXTONE1_Change
END IF
CASE %FORM1_LISTVIEW1
IF CMsg&=%EZ_Change THEN
FORM1_LISTVIEW1_Change CVal&
END IF
IF CMsg&=%EZ_Selected THEN
FORM1_LISTVIEW1_Select CVal&
END IF
CASE %FORM1_TREEVIEW1
IF CMsg&=%EZ_Selected THEN
FORM1_TREEVIEW1_Select CVal&
END IF
CASE %FORM1_HTRACKBAR1
IF CMsg&=%EZ_Change THEN
FORM1_HTRACKBAR1_Change CVal&
END IF
CASE %FORM1_DATETIME1
IF CMsg&=%EZ_Change THEN
FORM1_DATETIME1_Change
END IF
CASE %FORM1_TAB1
IF CMsg&=%EZ_Change THEN
FORM1_TAB1_Change CVal&
END IF
CASE ELSE
END SELECT
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_FILE_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_NEWFILE_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_OPENFILE_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_SAVEFILE_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_SAVEAS_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_EXIT_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_EDIT_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_CUT_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_COPY_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_PASTE_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_HELP_Select()
END SUB
' ------------------------------------------------
' ------------------------------------------------
SUB FORM1_HELP1_Select()
END SUB
' ------------------------------------------------

' ------------------------------------------------
SUB FORM1_BUTTON1_Click()
END SUB
' ------------------------------------------------
SUB FORM1_CHECK1_Click()
END SUB
' ------------------------------------------------
SUB FORM1_RADIO1_Click()
END SUB
' ------------------------------------------------
SUB FORM1_TEXT1_Change()
END SUB
' ------------------------------------------------
SUB FORM1_LISTBOX1_Change(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_COMBOBOX1_Change(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_VSCROLL1_Change(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_HSCROLL1_Change(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_UPDOWN1_Change(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_RICHTEXTONE1_Load(BYVAL Mode&, BYVAL D$)
END SUB
' ------------------------------------------------
SUB FORM1_RICHTEXTONE1_Change()
END SUB
' ------------------------------------------------
SUB FORM1_LISTVIEW1_Fill(BYVAL Mode&)
LOCAL R&, C&, Tmp$
IF Mode&=-1 THEN ' Initial Data
FOR R&=0 TO 50 ' Rows
FOR C&=0 TO 5 ' Columns
Tmp$="Item "+RIGHT$("00"+LTRIM$(STR$(R&)),2)+","+STR$(C&)
EZ_AddLVItem "Form1", %FORM1_LISTVIEW1, Tmp$, 0, R&, C&, ""
NEXT C&
NEXT R&
END IF
END SUB
' ------------------------------------------------
SUB FORM1_LISTVIEW1_Change(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_LISTVIEW1_Select(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_TREEVIEW1_Fill(BYVAL Mode&)
LOCAL N1&, N2&, hParent&, Prop$, hAfter&, P&
LOCAL TreeHandles&()
IF Mode&=-1 THEN ' Initial Data
DIM TreeHandles&(1 TO 3, 1 TO 3)
FOR N1&=1 TO 3
FOR N2&=1 TO 3
P&=1
hParent&=0
Prop$="{T}{S}+"
IF N2&>1 THEN
hParent&=TreeHandles&(N1&,1)
Prop$="{T}{S}+"
P&=2
END IF
IF N2&>2 THEN
hParent&=Treehandles&(N1&,2)
Prop$="{T}{S}"
P&=2
END IF
hAfter&=0
TreeHandles&(N1&,N2&)=EZ_AddTVItem("Form1", %FORM1_TREEVIEW1, hParent& , hAfter&, "Item"+STR$(N1&)+","+STR$(N2&),P&,0,Prop$)
NEXT N2&
NEXT N1&
END IF
END SUB
' ------------------------------------------------
SUB FORM1_TREEVIEW1_Select(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_HTRACKBAR1_Change(BYVAL CVal&)
END SUB
' ------------------------------------------------
SUB FORM1_DATETIME1_Change()
END SUB
' ------------------------------------------------
SUB FORM1_TAB1_Change(BYVAL CVal&)
EZ_DisplayLayer "Form1", CVal&, 0 OR %EZ_DECtrls
END SUB

EZGUI is event based and it would be nice to be able to do this in a thinbasic module.

EZGUI uses indexes for colors, just like DOS Basic does (colors 0 to 15 are predefined).
It uses character base coordinates, so you don't have to use pixels or dialog units. Character units though are floating point, so you can define down to the pixel using them.

Form creation is very easy with a simple command EZ_Form. When EZ_Form is called the form is created, but hidden and then EZGUI calls the EZ_DesignWindow routine passing the forms name and that is where you add controls and menus.

EZGUI handles the message loop and is in control. When a control has an event (ie. user clicks control) an event is generated and forwarded to the EZ_Events routine.

Forms have names (strings) and not handles like using he Windows API.

Controls have ID numbers.

Properties are passed using a very simple string, with one character representing a property. For example to have a textbox which can be edited, one would use the property string:

"EST"

E for editable
S for sunken edge border
T for tabstop

No API constants being OR'ed together. As "easy as pie", perfect for a novice.

The idea would be to create a freeware EZGUI thinbasic module for building user interfaces.

So for this to work, a thinbasic module would have to allow me to do the following:

(1) Call a startup function in the module and control would remain in the module

(2) The module would have to be able to generate a call to the EZ_Main routine in the thinbasic script and then you can call EZGUI module commands there.
One EZ_Form (or a subroutine called which contains it) command needs to be called in this part of the script to create the first form.

(3) Before EZ_Main in the script returns, the EZ_Form call will generate another callback from the module to EZ_DesignWindow which would require thinbasic to forward the call to the EZ_DesignWindow routine in the thinbasic script, where control creation commands will be called in the script.

(4) When EZ_DesignWindow finishes, then EZ_Main will be able to finish and once again the EZGUI module would be in control.

(5) When the EZGUI modules needs to generate an event, it would have to forward a call to the thinbasic script routine EZ_Events.

My GUI engine is not just a set of wrappers. It literally takes control and handles the message loop and all event processing.

Would the current state of thinbasic allow such a module, which require this kind of callback arrangement ?

ErosOlmi

01-05-2012, 11:20

Chris,

consider that apart thinBasic Core Engine (thinCore.dll) all other part of thinBasic are build as module.
It means that all I've developed as module you also can develop the same.

In particular thinBasic_UI.dll module (thinBasic User Interface module) is in charge to simulate Power Basic DDT and it does calling user script interpreted functions from inside the Module using special thinBasic SDK functions.

To understand thinBasic SDK for PowerBasic, I suggest to start simple and create a little experimental module maybe not UI related but just for experimenting.
Having done that, than we can talk about advanced situations like the one you mentioned in your post.
Also remember that the control must be in the hands of the Core Engine and not into the module because thinBasic in more a parser than a real interpreted and Core engine must continue to parse script source code.
If you pass control over to module, it is just calling an external program giving it full control, and this is not the case of thinBasic.

Ciao
Eros