Wish Include Files

[antonomase]

Hi,

In the editor, the code source can be very long. For avoiding to scroll up and down in a large file (even if you use regions), is it possible to add include directives to cut the file in several pieces ?

main.bas
Sub Globals
...
End Sub
#include ("firstpart.bas")
Sub anothersub
...
end sub

firstpart.bas
Sub something
...
End Sub
...

 

[Erel]

You should break your code into code modules or classes. In the long run it is much more maintainable then including text files.

 

[antonomase]

My problem is if I use the designer to design complex screens with a lot of views of different types (I have a layout for the settings of the app with more than 100 views : panels, labels, radio buttons, seekbars, buttons, toggle buttons, ...) I can't use these views in a code module or in a class.

I have to use them in the Main module unless to create a code module and use subs which is not very usefull to maintain

Main
Settings.LblTranslate (lng, lblSettings01, lblSettings02, lblSettings03, ...)
Settings.BtnTranslate (lng, btnSettings01, btnSettings02, btnSettings03, ...)

Module Settings
Sub LblTranslate (lng as String, lbl1 as Label, lbl2 as Label, lbl3 as Label, ...)
End sub
Sub BtnTranslate (lng as String, btn1 as Button, btn2 as Button, btn3 as Button, ...)
End sub

Other point : the views of my app are strongly dependent. When I click on one, a lot of other views are tested or changed. Same thing : if i cut my code into modules, i have to use function with lot of parameters.

Another solution is to use a Class, but you loose all the advantage of the visual designer : you have to size and position all the views in the source code.
I do it for a File Selector : I designed and test it with the designer and after I create a Class for this selector and in the Initialize event, I recreate all the views, the positions, the sizes, the text sizes, the colors, ... But it contains just 4 views !
It's impossible to do (and to maintain) with a populous layout.

It's why I propose to cut the Main source into include files. Or having the possibility of using the views of the designer in multiple modules.

But you're the boss

 

[stevel05]

You can load a layout within a class, by passing either a panel or the activity to a class then loading on there. See CDT.zip.

The Designer won't allow the use of generate members in a class, but you can just generate them in an activity and move them or create them manually.

If you pass a panel to the class and load the layout into that, you can then use the class from any activity, see CDT2.zip

Also see the Me object for calling subs in activities from classes.

 

[antonomase]

Thanks,

I will try

 

[PaulR]

I'd like this to be able to have the project data separate from the project code.

 

[Erel]

What do you mean with project data?

The project data should not be included in the project code.

 

[PaulR]

I mean in the b4a Main Activity file. It would be better to have the main activity code separate from the data relating to the project modules etc. I use a class at the moment with methods for each Activity call , but Process Globals still have to be in the b4a file. A simple fix would be an #include directive so that everything is the same as it was for anybody not encountering issues with VC ("a module was added, did the main activity code change too?") or code highlighting in other viewers that don't recognise the b4a extension.

 

[Erel]

Not sure that I completely understand. You can add a static code module and put process global variables there.

 

[PaulR]

Yes, this is true - thanks for pointing that out, this equals a the quick-fix #include for this purpose, but both will still leave activity events in the main b4a file whenever a requirement comes up for them. It's worth thinking about possible solutions for this anyway. On a side note, there's a distinct lack of published open source repos for b4a, which would be nice for projects and libraries alike. At the moment the b4a files don't look the best in the viewers with no code-highlighting and 8 space tabs (which could be fixed on the user side, yes) so making seemingly minor improvements could help the future eco-system of your product.

 

[sorex]

the code modules are indeed an alternative option but the problem is when you're used to flat scope programming that you run into a lot of problems to get the same sub working as code module sub. (you need to feed the objects/views to the subs if I recall right).

I would opt aswell for plain include style of modules that remain in the activity scope where the include was added.