ReneMiner

Hi Rene,

this is an interesting summary of important thoughts. Win32 is a jungle - powerful, but definitely not "BASIC".

Something to keep in mind for shaping UI module better...


Petr

I am really sad i have to say this. it's annoying me. But also a challenge to get something done even it seems impossible.
What was forgotten in my opinion is these %WM_-things - windows messages. There is a lot of "for further information visit the microsoft site at where.ever.it.was.aspx and find yourself lost. The point is is start to google for a keyword that i know must exist but i don't know the verb itself so i am browsing a lot of sites, sometimes older than thinbasic and when i think i've finally found what should be the solution i run into the next problem. It might be the right message or event but - just for that control in thinbasic this is not implemented

The help lacks an important part - even it has plenty of functions that wrap the sometimes cryptic windows message sending stuff
its missing a general explanation for the most common uses like - don't laugh: how do i know a control got focus?
If the user clicks it? what about if he uses keyboard or uses sendmessage from another program?

mostly the very basic things are nowhere to find. Listviews - allow groups and icons. Icons even for each and every subitem. How would the filelist of explorer look like if there were no icons that show if its a folder, a drive or what type of file it is. We would get crazy if we could not see those little images that save us a lot of reading.

And thinbasic? Listview...image... ooh wow - it can set a background-image. Who needs that?
when I look for a way to associate an imagelist to a certain column of the listview so column 1 might show a drive, usb-key -whatever - some device to store data and maybe in column 5 i like to use another imagelist showing a small piechart that visualizes the used storage and column 8 should display like the manufacturers logo because using these little images shortens
the time to understand such a table (or listview) enormously.

I don't know for how many months - or is it years already - i am trying to get a program done, but its always the same. I look for a solution of problem X and find a way to accomplish something else which seems fascinating and brings up many new ideas and i forget the previous problem and start something new where i mostly use one of those unfinished scripts that i wrote months ago as a base to start because i forgot what was the reason that i did not continue.

After few hours or sometimes days i remember. In some cases it does not matter because the new idea does not need that what i was not able to find in the past.

But sometimes i focus the same problem as months ago -

it's Groundhog day - again -

the feeling of no progress comes up even i know it's not real because i've found many uncommon ways in the meantime and plenty of unfinished scripts where i think if you would see how some of them work already it were only a matter of minutes until you decide to abandon UI-developement and create a new Module from scratch.

Not quite.
One almost forgotten part would survive and be the base where not only the user interface is build with but the new user interface is build upon.

The visual designer.

Imagine you modify a script while it's running. One step beyound WYSIWYG:

What you want is what you get. Not more than that. But not a bit less

Now you might wonder. To help you over the mental barricades built by logic conclusion and your life-long experience concerning the usage of programming languages i will start a small experiment and a short excurse by the speed of light will enlighten you.

Read it twice or more often until you get the meaning and understand the answer and why the wrong answer might come up in our heads

Albert Einstein said: "Nothing is faster than light."
Thats proven. A fact that can be calculated repeatedly and will always lead to the same result.

Now i will ask you: Is there anything known to you that is faster than the speed of light?

What was your reply? Was your answer "No" ?

Wrong answer.

I will ask you again and you will answer correct this time and explain your answer:

Do you know anything that moves at faster speed than light?

Yes. I know NOTHING. NOTHING moves faster than light.

Correct.

Welcome to the reality.
Now to something so absurd as running a thinBasic-script while editing it.

A statement that Eros made some time ago brought me to the idea. It was about embedding thinBasic as script-language
to powerbasic has been an initial idea and once upon a time the intended purpose of thinBasic developement and his final comment was:

"... in the meantime thinBasic has grown way beyond the point to serve as scripting language for another programming language."

He is right. Read the last sentence until you understand it in its most important essence as you did with the sentence in the beginning and until detect that your imagination begins to become more than just an idea.

To give you a push: focus on the verb "another"

obviously the puzzle was too complex to solve? Or was it just nobody had time for it?

When you create a .dll in powerbasic for example then you wish sometimes to have a thinBasic-function available - but a core- or module-function not a script-function because it would be much easier to reach the desired result. You have the option to include a .tBasicI-file to your package where you would write the desired thinbasic-function-call and call this from the dll. But huh? Such thing will not become a module - or do you know any module that requires an additional thinBasic-script?

Rarely. And prefereable were it to have the module complete in one piece. You can.

Your .dll should embed thinBasic. And run the scripts that can be stored as strings within the .dll

That's one way. Reducing .dlls size probably a bit if you stick with small scripts since the functions to call are already contained in thinbasic-modules.

Another way were a thinbasic-script that uses a .dll just as a launching platform to integrate a new piece of code (virtually)... to test it.
If the new piece were just dialogs or controls to add the actual running script can easily destroy any added item because it creates the script that runs by the way - as the .dll - in the same process as the main-script and can access any windows-objects of it. And because the .dll can provide real function pointers ( codepointers in pb or AddressOf in vb6) and the tb-main-script can inform the dll at any time if objects have been destroyed it will serve to have a fist ful of dummy-functions to borrow the adresses. if the dummies are all in use and none shall be destroyed its time to stop, save and add the accepted stuff to the project.