[Wish] Plug-Ins for IDE/Compiler

Jost aus Soest

Active Member
Licensed User
Longtime User
It would be very useful to have some kind of plug-in-mechanism for B4A, so we can have running some individual logic for specific IDE- or (Pre)Compiler-Events like
- After New Code Line is entered [NL]
- After Loading a File [LF]
- Before/After Saving a File [SF]
- Before/After Code Analyze [CA]
- Before/After PreCompiling to Java [CJ]
- Before/After Compiling to Bytecode [CB]
- Before/After Generating APK [GA]
- Before/After Transferring to Device [TD]

With that we could introduce some personal features like Auto Corrections (e. g. "flase" to "false" by using [NL]) or Version Control (by using [SF]), but also new language features like Overloading (by using [CA] and [CJ]).

Erel, I'm not talking about an extensive API!

IMHO it would be enough to have some Batch-Calls (e. g. AfterNL.bat or BeforeCJ.bat), where we can embed our code/programs. If one of this Event-Batch exists, the B4A-IDE calls it (in the right moment).
Input-param normaly would be the location of the specific source file (resp. the new Code Line), which can be modified by the "Plug-In".
 

Jost aus Soest

Active Member
Licensed User
Longtime User
Menu items for calling external programs/shell scripts

It would be also very useful to embed Batch-calls in the menus of the B4A-IDE.

E. g. all BAT-Files in a specific directory will be displayed in a new "Batches"-menu (between "Tools" and "Help", omitting the ".bat" suffixes).
A click on a menu item will simply start the corresponding batch.

(I personally would use this to start my Android-VM and establish the connection.)
 

GMan

Well-Known Member
Licensed User
Longtime User
+1
 

Troberg

Well-Known Member
Licensed User
Longtime User
While it would be very useful (for example, to create pre-compiler macros), it would not be without problems. I suspect some parsing is made while editing, for coloring and IntelliSense. This means that the plugin would have to be quite fast, as (in some cases), it would be called very often.
 

cimperia

Active Member
Licensed User
Longtime User
+1
 

cimperia

Active Member
Licensed User
Longtime User
I usually do not respond to most feature requests.

Why is that? I would have thought that listening to what your customers want is rule number one to stay in business?
 

sorex

Expert
Licensed User
Longtime User
it's not that he didn't respond that it is not added on his to-check, to-do list and might be implemented one day.
 

Troberg

Well-Known Member
Licensed User
Longtime User
Why is that? I would have thought that listening to what your customers want is rule number one to stay in business?

I understand him. Once you go into discussions about what to include or not, as a product owner you inevitably end up as the bad guy because someone didn't get their pet feature.

It's better to just maintain a list of optional developments, and them map them to your vision, and implement those that fit the vision. That also makes for a much more coherent and thought-through product.
 
Top