Next version new features

[Erel]

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.

 

[Cableguy]

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?

 

[Erel]

Still, will some other of the wishlist suggestion be implemented?

There will be other new features as well. However it is too early to say which features.

 

[agraham]

The version after this one will focus on an improved types system.

I've already been thinking about this. Here is my initial haporth ha’p’orth definition - Dictionary - MSN Encarta on typing

 

[Erel]

I like your suggestions agraham.
It will not be simple to fully implement all of this but the reason behind it is clear.

The "typed" version is still pretty far. Please feel free to also express your thoughts about the "modules" version.

 

[alfcen]

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.

 

[Erel]

Could this later be extended to the capability of saving
forms as individual files that can be imported into a project?

Maybe in a future version.
I'm sure that you are aware of the FormDuplicator which allows you to copy forms between projects: http://www.b4x.com/forum/official-updates/1511-formduplicator-tool-copy-forms-between-projects.html

 

[WZSun]

Flush function

'Flush' keystroke, taps and button presses.

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.

 

[klaus]

Hi Erel,

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.

Best regards.

 

[agraham]

Another haporth making a full pennorth now Includes some comments on function return types, b4p delegates and For loops

Please feel free to also express your thoughts about the "modules" version.

:signOops: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.

 

[GeoTrail]

This looks like an exiting new path for B4PPC.
Maybe one day we can compile DLL's directly from the IDE

 

[Erel]

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.

Only the desktop IDE will support tabbed editing.

You can think of modules as singleton objects (or static / shared objects).
I think that the module prefix together with AutoComplete (which will only show the public fields) will be very handy.
The code should be more clear as you will be able to see right away where does each sub come from.

 

[WZSun]

I see lots of possibilities using modules..

Imagine this:

Program.exe (small size, actually a simple loader)
Menu.mod (encrypted modules)
Program1.mod (encrypted modules)
Program2.mod (encrypted modules)
...
Program3.mod (encrypted modules)


Program.exe loads menu.mod and display a screen selection. User can select Option 1, 2, or 3.. and it will then load the ProgramX into memory; and offload Menu.mod so that memory is optimized.

This is useful for anyone who writes different modular addons for projects.

 

[agraham]

I don't think the Modules that Erel is proposing will help at all for this sort of thing. A B4ppc program implemented in modules will compile into a single application. The modules will be a (welcome) way of compartmentalising code and hiding implementation details by only having Public interfaces exposed to other Modules and the main program.

To implement what you describe in B4ppc requires separately compiled applications implemented as exe or dll.

 

[Mr_Gee]

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 love this idea maybe AppPath and the default install folder under/BAS
that way you can put the frequently used items under the install dir, and project specific items under the AppPath.

Also an easy way to import these .BAS files would also be nice
e.g. Tools>Modules>
import - would give you a OpenFile dialog
select - would show you the modules in the B4P install folder


Just being curious, when is the next release scheduled?
and where can i sign up for the beta test :sign0060:

 

[Erel]

I want to update you all that controls and objects will not be global as I first wrote.
Instead each module will have its own set of controls and objects (which will be accessible by other modules). Making it much easier to reuse modules.

Just being curious, when is the next release scheduled?
and where can i sign up for the beta test :sign0060:

I hope to release a beta version during September. Any help with testing the beta version will be highly appreciated
You will be able to join the beta testers group after the release.