Next version major improvement will be support for modules.
Modules are units of code. Each module can have its own set of subroutines and global variables (which are declared in the module's "Globals" subroutine).
Each sub and global variable can have the "public" access modifier.
Only public subs and variables will be accessible outside of their module.
Objects and controls will be global to all modules.
Accessing a sub or variable in a different module will be done by writing the module name followed by a period and then the actual value.
On the desktop IDE you will be able to view each module in a different tab.
Each module will be saved to a different file (the module name with .bas extension).
These new features will be very helpful with writing large projects and sharing code between several projects.
The version after this one will focus on an improved types system.
You are more than welcomed to share your ideas about this and how it should be implemented.
It's almost like being able to "create" your own "dll's", but all in B4P...And always re-usable..
Great improvement....
Still, will some other of the wishlist suggestion be implemented?
__________________
Paulo Gomes - Porto, Portugal - Living/Working in France
Mobile Device: Samsung Galaxy S, Android 2.3.4 CUstom ROM
Laptop: Toshiba NB100-130 (running on Win7Ultimate)
My Posts helped you? Consider Buying me a Porto Glass!
The modular concept is a highly welcome enhancement.
Could this later be extended to the capability of saving
forms as individual files that can be imported into a project?
Frequently re-used forms are Settings and About screens,
but not exclusively.
Currently, when an action is being processed, any keystroke, screentap, button pressed will be 'detected' and kept in memory. When the process has been completed, these keystrokes will then be executed.
In many cases, these may lead to different forms being shown (in cases when the process is long, and users tapping on various buttons, etc), wrong actions being performed, and unpleasant scenarios.
Having a flush function would clear all current keystrokes in memory. Apart from having a better controlled program, it has some preventive (protection) usage as well.
I'm shure that this will be a big improvement, which will allow to share common code between projects an even have a better code structure than with the Region option.
It would be interesting that the modules could be in different directories. In my programs there is some common code that could be in one or several modules in a general directory and the specific code for a specific program in it's specific directory. So all projects look for these general modules in the same directory and no need to copy them to all project directories.
I fully support alfcen's proposal for Forms, that they could be saved individually or why not belong to a module. Unfortunately, the FormDuplicator copies only a Form to the target project but not the code that belongs to, FormEvents ControlEvents etc. Having the form saved with it's code means saving the whole functionality of the form, not only it's graphics.
For the dll's, the IDE knows where they are, why always need to copy those to the program's directory and not only specify which ones are used, especially now that most of them are merged to the exe file. If the non merged dlls must be copied to the directory why not. But the ideal case would be that all needed libraries are merged to the exe file.
In the IDE it would be usefull to have a listbox or a combobox with the list of all controls. If there are many on a form, it would be much easier to select one instead of clicking and clicking the next button, and as I often do, missing it.
Could some of the official dlls, with complementary functionalities like the Formlib or with new Controls like the ControlEx library be integrated into the IDE, if I remember well, it was a request from Cableguy some time ago.
I also fully subscribe to agraham's proposals for the variable transfer between Subroutines.
Of course these are for shure no critics at all, but suggestions and wishes to make this fantastic product more and more brilliant.
Another haporth making a full pennorth now Includes some comments on function return types, b4p delegates and For loops
Quote:
Originally Posted by Erel
Please feel free to also express your thoughts about the "modules" version.
Sorry, I misunderstood your post. When you said "about this" I thought it implied that Module details were settled and you were asking about types
I think Modules are a very good idea and only involve a single addition to the B4ppc syntax 'Public'. I assume that the mechanism will be based on the existing capability of referencing source files as components so keeping compatibility with the device IDE which I assume (maybe wrongly?) won't support tabbed editing
I am less sure about the need for module name prefixing, the .NET languages get away without it for objects in referenced assemblies except where it is needed in the case of a name clash. It might also make AutoComplete a bit clumsy.
Next version new features
Here is my initial haporth 
Sorry, I misunderstood your post. When you said "about this" I thought it implied that Module details were settled and you were asking about types 
Linear Mode
