[Wish] Plug-Ins for IDE/Compiler

[Jost aus Soest]

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".

 

[Toley]

+1

 

[Alex69]

+1

 

[Jost aus Soest]

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.)

 

[icefairy333]

+1
Strongly recommended for this function

 

[JakeBullet70]

+1

 

[GMan]

+1

 

[icefairy333]

+1 again
@Erel
I think it's very useful,in that way we can make a plugin to parse the android.jar to get some constants like View.* Intent.* and also from many third party jar.

 

[Erel]

You can create a simple sub that returns the constant value. If you need more information then please start a new thread.

 

[Troberg]

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.

 

[shugeyi]

+1

 

[zkc20130508]

+1

 

[xhmeng]

+1

 

[cimperia]

+1

 

[JakeBullet70]

Any news on this Erel?

 

[Erel]

I usually do not respond to most feature requests. It will be considered.

The custom build actions already support some of these features. Running a batch file when the developer enters a new line or modifies the code is not really feasible.

 

[cimperia]

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]

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]

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.