Automatic import of custom code during compilation

gruz commented

2017-01-27 15:10:19 +00:00

(Migrated from github.com)

If I want to create and debug my code (sometimes editing several files) I must every time manually save it to JCB. I may edit several files in several places. I cannot fixate my latest code changes, I must copy-paste and save it to JCB backend. This promises to be problematic and error causing.

Surely, if I'd have 100% working custom code at the beginning of a component, I'd be able to place it to JCB. But custom coding and instead of ctrl+s to save it copy-paste to the correct tab in the correct view in backend is something to cause much problems. For me it kills the benefits of JCB, except the intial coding.

So there is an idea to improve JCB. I'm not familiar how JCB works, but I suspect it inserts the custom code added in the JCB backend to the resulting code. Why not to do vice versa as well to import manual code changes made while testing?

Make a convention to use some placeholder like

/*#$#$#$ start custom code #$#$#$*/ 
$myCustomPhpCode = true; /// Some code
/*#$#$#$ end custom code #$#$#$*/.

So the 'import' feature would parse the already built and installed component and update the JCB component backend fields from the installed files.

So there would be an option to import the latest code changes from the installed component and after that build/install the component again (to change the component version, deploy it etc.)

This would concern also custom added files, which should be added to the project automatically.

As far as I remember, I've seen a feature like this when trying different component builder extensions.

If I want to create and debug my code (sometimes editing several files) I must every time manually save it to JCB. I may edit several files in several places. I cannot fixate my latest code changes, I must copy-paste and save it to JCB backend. This promises to be problematic and error causing. Surely, if I'd have 100% working custom code at the beginning of a component, I'd be able to place it to JCB. But custom coding and instead of ctrl+s to save it copy-paste to the correct tab in the correct view in backend is something to cause much problems. For me it kills the benefits of JCB, except the intial coding. So there is an idea to improve JCB. I'm not familiar how JCB works, but I suspect it inserts the custom code added in the JCB backend to the resulting code. Why not to do vice versa as well to import manual code changes made while testing? Make a convention to use some placeholder like ``` /*#$#$#$ start custom code #$#$#$*/ $myCustomPhpCode = true; /// Some code /*#$#$#$ end custom code #$#$#$*/. ``` So the 'import' feature would parse the already built and installed component and update the JCB component backend fields from the installed files. So there would be an option to import the latest code changes from the installed component and after that build/install the component again (to change the component version, deploy it etc.) This would concern also custom added files, which should be added to the project automatically. As far as I remember, I've seen a feature like this when trying different component builder extensions.

Llewellyn commented

2017-01-27 20:24:45 +00:00

This sounds like an very great idea... and I think it can be done with the JCB and it should not be to hard either.

Okay lets see... there is a few files that you should get to know, since it is in them that all the work is done. They are in the compiler folder in the back-end

Each of there names mean what it does... so:

a_Get.php (gets the data from the DB and is the first in the stack)
b_Structure.php (is what builds the file structure)
c_Fields.php (sets up all the fields)
e_Interpretation.php (is the place where the advanced concepts are done, should be re-factored)
f_Infusion.php (sets up the array that holds the values that should replace the placeholders in the structure)

Then lastly the file that brings it all in to action, and where I think we should add this new feature
The Compiler

I have added this feature request to a project, and I will start working on a road map... to achieve this objective.

Tell me @gruz are you willing to help make this happen?

I have a few questions that you can give me your feedback on.

Once you have garbed/extracted the code from the file between those placeholder, how will you know where to place it in the new file?

same line is what seems like the only option, but there are a few limitations that will then naturally follow. Like if new code is added to the file then the line numbers will change. What are your thought on the matter?

How will you be able to update code generated by JCB, this again deals with how do we know where to place the code extracted, and how do we know it should replace another auto generated part of the code?

I don't know, but we could add line numbers to the placeholder convention that will help the JCB know that from line 10 to 15 it should replace the generated code... but it is risky... we need something more stable.

How will the system remember that code so it can add it in the future?

It should store it somewhere in the system, so a new table and view should be added. This seems like the most natural solution.

Okay what if you want to change that code, by adding more code to it, or change some part of it, and or remove it?

Well here it gets very tricky... we could add another convention, to surround code that was build with this feature, that will link it to the DB in compilation, but to also be able with these placeholder convention announce that a custom script already exist in the DB and should be change or remove. So a smart placeholder convention should be formulated. Or you could just in the system edit it or delete it... hmmm

Do you have any ideas on how this smart/intelligent placeholders concept could work and look?

I do, but please share your thought..

Should this feature work in all file types and languages?

I think it should only work on PHP files to start with, and only on PHP files that the system generates. But we could latter extend it once we get it to work as expected. What do you think?

Well I think this will serve as a good start to the conversation... looking forward to get this done!

This sounds like an very great idea... and I think it can be done with the JCB and it should not be to hard either. Okay lets see... there is a few files that you should get to know, since it is in them that all the work is done. They are in the [compiler folder in the back-end](https://github.com/vdm-io/Joomla-Component-Builder/tree/master/admin/helpers/compiler) Each of there names mean what it does... so: - [a_Get.php](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/a_Get.php) (gets the data from the DB and is the first in the stack) - [b_Structure.php](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/b_Structure.php) (is what builds the file structure) - [c_Fields.php](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/c_Fields.php) (sets up all the fields) - [e_Interpretation.php](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/e_Interpretation.php) (is the place where the advanced concepts are done, should be re-factored) - [f_Infusion.php](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php) (sets up the array that holds the values that should replace the placeholders in the structure) Then lastly the file that brings it all in to action, and where I think we should add this new feature [The Compiler](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler.php) I have added this feature request to a project, and I will start working on a road map... to achieve this objective. Tell me @gruz are you willing to help make this happen? ## I have a few questions that you can give me your feedback on. **Once you have garbed/extracted the code from the file between those placeholder, how will you know where to place it in the new file?** > same line is what seems like the only option, but there are a few limitations that will then naturally follow. Like if new code is added to the file then the line numbers will change. What are your thought on the matter? **How will you be able to update code generated by JCB, this again deals with how do we know where to place the code extracted, and how do we know it should replace another auto generated part of the code?** >I don't know, but we could add line numbers to the placeholder convention that will help the JCB know that from line 10 to 15 it should replace the generated code... but it is risky... we need something more stable. **How will the system remember that code so it can add it in the future?** >It should store it somewhere in the system, so a new table and view should be added. This seems like the most natural solution. **Okay what if you want to change that code, by adding more code to it, or change some part of it, and or remove it?** >Well here it gets very tricky... we could add another convention, to surround code that was build with this feature, that will link it to the DB in compilation, but to also be able with these placeholder convention announce that a custom script already exist in the DB and should be change or remove. So a smart placeholder convention should be formulated. Or you could just in the system edit it or delete it... hmmm **Do you have any ideas on how this smart/intelligent placeholders concept could work and look?** >I do, but please share your thought.. **Should this feature work in all file types and languages?** > I think it should only work on PHP files to start with, and only on PHP files that the system generates. But we could latter extend it once we get it to work as expected. What do you think? Well I think this will serve as a good start to the conversation... looking forward to get this done!

gruz commented

2017-01-27 23:40:38 +00:00

(Migrated from github.com)

Once you have garbed/extracted the code from the file between those placeholder, how will you know where to place it in the new file?

I don't see the problem at all. You have placeholder to place the code from JCB database. And you replace the code in the JCB database with the code from the file on "import". Line number doesn't matter.

How will you be able to update code generated by JCB, this again deals with how do we know where to place the code extracted, and how do we know it should replace another auto generated part of the code?

I'd suggest to use placeholder. Why not? The only disadvantage is the placeholders are placed in the production code. First of all I don't think a PHP comment is/should be a problem. But there can be 2 types of compilation - production and development. This without the placeholders and with it.

How will the system remember that code so it can add it in the future?

I don't understand the problem. You have fields from custom PHP code in JCB now. So the fields can be either filled with manually or on import.

Okay what if you want to change that code, by adding more code to it, or change some part of it, and or remove it?

The developer should take care of having no conflicts. So if changed the code in the installed component, one must import it into JCB. If changing code in JCB manually, one must compile and reinstall the component. And one must care not to overwrite one's code.

Do you have any ideas on how this smart/intelligent placeholders concept could work and look?

Something easy to be parsed.

/* Start custom code here */
/*#J#C#B#{*/
...my code
/*#J#C#B#}*/
/* End of custom code */

Should this feature work in all file types and languages?

The most problematic is PHP and JS. Language files can be updated manually.

> Once you have garbed/extracted the code from the file between those placeholder, how will you know where to place it in the new file? I don't see the problem at all. You have placeholder to place the code from JCB database. And you replace the code in the JCB database with the code from the file on "import". Line number doesn't matter. > How will you be able to update code generated by JCB, this again deals with how do we know where to place the code extracted, and how do we know it should replace another auto generated part of the code? I'd suggest to use placeholder. Why not? The only disadvantage is the placeholders are placed in the production code. First of all I don't think a PHP comment is/should be a problem. But there can be 2 types of compilation - production and development. This without the placeholders and with it. > How will the system remember that code so it can add it in the future? I don't understand the problem. You have fields from custom PHP code in JCB now. So the fields can be either filled with manually or on import. > Okay what if you want to change that code, by adding more code to it, or change some part of it, and or remove it? The developer should take care of having no conflicts. So if changed the code in the installed component, one must import it into JCB. If changing code in JCB manually, one must compile and reinstall the component. And one must care not to overwrite one's code. > Do you have any ideas on how this smart/intelligent placeholders concept could work and look? Something easy to be parsed. ``` /* Start custom code here */ /*#J#C#B#{*/ ...my code /*#J#C#B#}*/ /* End of custom code */ ``` > Should this feature work in all file types and languages? The most problematic is PHP and JS. Language files can be updated manually.

Llewellyn commented

2017-01-29 01:36:29 +00:00

There is a little more complexity here... JCB adds a lot of code on the fly and so we will need to take much more caution or it will break. The way the compiler works is like on massive big object and trying to poke in on the data in reverse will be extremely hard.

I don't see the problem at all. You have placeholder to place the code from JCB database. And you replace the code in the JCB database with the code from the file on "import". Line number doesn't matter.

This will not work, the placeholders are so many and on so many places that to keep track of that will be insane. We will have to add a new table to deal just with this feature, so that things don't get confusing. Further you do realize using the existing placeholder will limit where you can change code, where as if we made it that you can change any code any where it would be ideal... this is what I think we should aim for.

I don't understand the problem. You have fields from custom PHP code in JCB now. So the fields can be either filled with manually or on import.

Again the same problem those fields target specific areas in the code, so if we store the new custom code in it, then that custom code can only be added to those specific areas. This will not be ideal... so we will need a new structure/table to store all custom imported code. That is no worries, I am almost done with this anyway.

But there can be 2 types of compilation - production and development. This without the placeholders and with it.

Hmm I think we can make sure that our place holders look like normal comments so it will not matter. Yet I think a switch to turn off the placeholder comments would not be that hard... so yes lets add that also.

There is a little more complexity here... JCB adds a lot of code on the fly and so we will need to take much more caution or it will break. The way the compiler works is like on massive big object and trying to poke in on the data in reverse will be extremely hard. > I don't see the problem at all. You have placeholder to place the code from JCB database. And you replace the code in the JCB database with the code from the file on "import". Line number doesn't matter. This will not work, the placeholders are so many and on so many places that to keep track of that will be insane. We will have to add a new table to deal just with this feature, so that things don't get confusing. Further you do realize using the existing placeholder will limit where you can change code, where as if we made it that you can change any code any where it would be ideal... this is what I think we should aim for. > I don't understand the problem. You have fields from custom PHP code in JCB now. So the fields can be either filled with manually or on import. Again the same problem those fields target specific areas in the code, so if we store the new custom code in it, then that custom code can only be added to those specific areas. This will not be ideal... so we will need a new structure/table to store all custom imported code. That is no worries, I am almost done with this anyway. > But there can be 2 types of compilation - production and development. This without the placeholders and with it. Hmm I think we can make sure that our place holders look like normal comments so it will not matter. Yet I think a switch to turn off the placeholder comments would not be that hard... so yes lets add that also.

gruz commented

2017-01-29 10:54:24 +00:00

(Migrated from github.com)

My idea was exactly to be able to import the custom code, which could be added from JCB backend. I cannot imagine, how any code can be imported. But as you wish :-)

Is there any thing I can help with?

My idea was exactly to be able to import the custom code, which could be added from JCB backend. I cannot imagine, how any code can be imported. But as you wish :-) Is there any thing I can help with?

Llewellyn commented

2017-01-29 17:10:25 +00:00

Okay I understand... but I am sure you agree import any code from any where is much more useful :)

I am almost ready with a prototype in four more days it all depends, since I am also working on other projects, so as soon as its ready I will push it up and you can help me test it to see if it works as expected... then you can help improve it (where needed) so we can make sure it does not kill our memory... this I think will be the biggest challenge.... because we are actually going to have tones of strings flying around.

IF we could use BASH or Python this well be much easier... but since this is a PHP project we will try our best to stay in PHP.

I will explain more soon as the code is ready for beta testing...

Okay I understand... but I am sure you agree import any code from any where is much more useful :) I am almost ready with a prototype in four more days it all depends, since I am also working on other projects, so as soon as its ready I will push it up and you can help me test it to see if it works as expected... then you can help improve it (where needed) so we can make sure it does not kill our memory... this I think will be the biggest challenge.... because we are actually going to have tones of strings flying around. IF we could use BASH or Python this well be much easier... but since this is a PHP project we will try our best to stay in PHP. I will explain more soon as the code is ready for beta testing...

Llewellyn commented

2017-01-29 18:58:35 +00:00

Here is my placeholder suggestion

New Insert Code		= /***[INSERT<>$$$$]***/ your code here /***[/INSERT<>$$$$]***/
New Replace Code	= /***[REPLACE<>$$$$]***/ your code here /***[/REPLACE<>$$$$]***/

//////// When JCB adds it back
JCB Add Inserted Code	= /***[INSERTED$$$$]***///23 your code here /***[/INSERTED$$$$]***/
JCB Add Replaced Code	= /***[REPLACED$$$$]***///25 your code here /***[/REPLACED$$$$]***/

////////  Changeing existing custom code
Update Inserted Code	= /***[INSERTED<>$$$$]***///23 your code here /***[/INSERTED<>$$$$]***/
Update Replaced Code	= /***[REPLACED<>$$$$]***///25 your code here /***[/REPLACED<>$$$$]***/

//23 is the ID of the code in the system don't change it!!!!!!!!!!!!!!!!!!!!!!!!!!

What do you think? would we need any more?

So when you add custom code you should tell if it is to be inserted or if it should replace existing code.

To see the note in the code.

Here is my placeholder suggestion ``` New Insert Code = /***[INSERT<>$$$$]***/ your code here /***[/INSERT<>$$$$]***/ New Replace Code = /***[REPLACE<>$$$$]***/ your code here /***[/REPLACE<>$$$$]***/ //////// When JCB adds it back JCB Add Inserted Code = /***[INSERTED$$$$]***///23 your code here /***[/INSERTED$$$$]***/ JCB Add Replaced Code = /***[REPLACED$$$$]***///25 your code here /***[/REPLACED$$$$]***/ //////// Changeing existing custom code Update Inserted Code = /***[INSERTED<>$$$$]***///23 your code here /***[/INSERTED<>$$$$]***/ Update Replaced Code = /***[REPLACED<>$$$$]***///25 your code here /***[/REPLACED<>$$$$]***/ //23 is the ID of the code in the system don't change it!!!!!!!!!!!!!!!!!!!!!!!!!! ``` What do you think? would we need any more? So when you add custom code you should tell if it is to be inserted or if it should replace existing code. [To see the note in the code](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/a_Get.php#L55).

Llewellyn commented

2017-02-01 10:40:49 +00:00

Hi @gruz great news... the prototype is ready for testing.

I still need to add some switches and warnings... but the actual "Automatic import of custom code during compilation" is ready and working...

I am wondering if it will help if I also make a sort tutorial, so you can help test this and give me feedback.

I will push the changes up in the next hour or so... looking forward to hear from you.

Hi @gruz great news... the prototype is ready for testing. I still need to add some switches and warnings... but the actual "Automatic import of custom code during compilation" is ready and working... I am wondering if it will help if I also make a sort tutorial, so you can help test this and give me feedback. I will push the changes up in the next hour or so... looking forward to hear from you.

gruz commented

2017-02-01 11:17:48 +00:00

(Migrated from github.com)

Hi, Llewellyn.

Cool news!

I have two problems before I can test:

I have 3 small but urgent projects to be finished. I hope to finish by the end of the week.
I didn't yet build a component with JCB. I did several tries, but didn't had a strong component need to force me to build something working. Before I asked about the feature, I had an idea, but since I could not implement it quickly, I switched to a plugin way to implement the same functionality. So I don't have something just "to start testing immediately". Maybe you should give me some test cases so I could help you. Otherwise I must develop a component using JCB, which I have no passion to develop right now. I will surely have a need in the coming future. Anyway that's a great feature.

Hi, Llewellyn. Cool news! I have two problems before I can test: 1. I have 3 small but urgent projects to be finished. I hope to finish by the end of the week. 2. I didn't yet build a component with JCB. I did several tries, but didn't had a strong component need to force me to build something working. Before I asked about the feature, I had an idea, but since I could not implement it quickly, I switched to a plugin way to implement the same functionality. So I don't have something just "to start testing immediately". Maybe you should give me some test cases so I could help you. Otherwise I must develop a component using JCB, which I have no passion to develop right now. I will surely have a need in the coming future. Anyway that's a great feature.

Llewellyn commented

2017-02-01 11:51:11 +00:00

Hey @gruz not a problem... if you install the latest JCB it comes with a demo component.

So you can compile that component install it on your Joomla site (this should just work out of the box) and in it add just a few custom code snippets, then run the compiler again and see if it retains the custom code in the correct place.

There are a few rules to this feature, I will explain in the tutorial :) I am planning to make this tutorial public.

You don't need to add more pressure to yourself, just give me the feedback on how it worked for you once you have had the time to test it.

Hey @gruz not a problem... if you install the latest JCB it comes with a demo component. So you can compile that component install it on your Joomla site (this should just work out of the box) and in it add just a few custom code snippets, then run the compiler again and see if it retains the custom code in the correct place. There are a few rules to this feature, I will explain in the tutorial :) I am planning to make this tutorial public. You don't need to add more pressure to yourself, just give me the feedback on how it worked for you once you have had the time to test it.

gruz commented

2017-02-01 11:52:51 +00:00

(Migrated from github.com)

Thanks. I'll test in several days or sooner. Maybe there will be the tutorial released by that time.

Llewellyn commented

2017-02-01 13:32:43 +00:00

Hi, the tutorial is ready on youtube, and I just pushed the changes onto version 2.2.9

Enjoy!!

Hi, the tutorial is ready on [youtube](https://youtu.be/DFMfIl-VkSk), and I just pushed the changes onto version 2.2.9 **Enjoy!!**

mwweb commented

2017-02-08 01:35:42 +00:00

Hi Llewellyn. Let me first say that this looks like it could be a really powerful addition to Component Builder. That being said, I've been running some tests on this, and have found a couple of issues.

As a test, I tested adding some custom code to an admin view. The code used was:
/***[INSERT<>$$$$]***/ echo 'this is a test'; /***[/INSERT<>$$$$]***/

After compile, the code had been detected and was showing in the custom code section of component builder. However, in the actual code itself, what was compiled was:
////////////////////////////////////////// echo 'this is a test'; //////////////////////////////////////////

On install of the version with this code, even though it's not correct, the installed ends up dropping all of the component tables, which poses a major issue.

I'm running v.2.3.0.

Hi Llewellyn. Let me first say that this looks like it could be a really powerful addition to Component Builder. That being said, I've been running some tests on this, and have found a couple of issues. 1. As a test, I tested adding some custom code to an admin view. The code used was: `/***[INSERT<>$$$$]***/ echo 'this is a test'; /***[/INSERT<>$$$$]***/` After compile, the code had been detected and was showing in the custom code section of component builder. However, in the actual code itself, what was compiled was: ` ////////////////////////////////////////// echo 'this is a test'; //////////////////////////////////////////` 2. On install of the version with this code, even though it's not correct, the installed ends up dropping all of the component tables, which poses a major issue. I'm running v.2.3.0.

Llewellyn commented

2017-02-08 03:11:29 +00:00

Hi, Thanks for the feedback... and yes we will work on this till it runs stable 👍

For now please insure the insert code are on its own line and not on the same lines as the insertion script... like this

/***[INSERT<>$$$$]***/ 
echo 'this is a test'; 
/***[/INSERT<>$$$$]***/

This should resolve the issue for now... but I will be working on that to insure it thinks head...

There is an update coming soon, I am just in the middle of another project that is past its due date... but soon this new feature in JCB will have my full attention again.

Hi, Thanks for the feedback... and yes we will work on this till it runs stable :+1: For now please insure the insert code are on its own line and not on the same lines as the insertion script... like this ``` /***[INSERT<>$$$$]***/ echo 'this is a test'; /***[/INSERT<>$$$$]***/ ``` This should resolve the issue for now... but I will be working on that to insure it thinks head... There is an update coming soon, I am just in the middle of another project that is past its due date... but soon this new feature in JCB will have my full attention again.

mwweb commented

2017-02-08 03:34:21 +00:00

In my code I actually did have it on different lines. It was in the post, after submitting, that it put it in a single line. I tried it 5 or 6 times and it did the same thing each time.

Llewellyn commented

2017-02-08 12:17:51 +00:00

Okay, are you on a windows Box?

mwweb commented

2017-02-08 16:08:00 +00:00

Yes, running xampp.

Llewellyn commented

2017-02-09 16:13:08 +00:00

Please upgrade to v2.3.1 and try again... for testing

mwweb commented

2017-02-12 01:57:25 +00:00

OK, there's still something "off" with it. It's compiling fine, except it is not including "JCB Add Inserted Code = /[INSERTED$$$$]///23 your code here /[/INSERTED$$$$]/" into the code.

Here's a screenshot of what I am putting in the code:

After compile:

Note that the compile stripped the insert tags out.

I'm running 2.3.2 on localhost, using XAMPP. I also backed up my localhost, uploaded to an account on my hosting server, and same result.

OK, there's still something "off" with it. It's compiling fine, except it is not including "JCB Add Inserted Code = /***[INSERTED$$$$]***///23 your code here /***[/INSERTED$$$$]***/" into the code. Here's a screenshot of what I am putting in the code: ![test1](https://cloud.githubusercontent.com/assets/19194012/22859005/600b3cb0-f083-11e6-88cc-279d180e865c.png) After compile: ![test2](https://cloud.githubusercontent.com/assets/19194012/22859006/64d2068e-f083-11e6-8669-3a999bec34a2.png) Note that the compile stripped the insert tags out. I'm running 2.3.2 on localhost, using XAMPP. I also backed up my localhost, uploaded to an account on my hosting server, and same result.

Llewellyn commented

2017-02-12 16:29:31 +00:00

Okay the new version has a switch in the component that needs to be switched on to insure that it adds the placeholders :) sorry I will soon make another tutorial of this feature to more fully explain how things work...

So open the component and set the switch [Custom Code Placeholders] to yes...

There is a new more stable version coming out soon, the version you are on is already WIN ready as you see the line breaks are working now...

Okay the new version has a switch in the component that needs to be switched on to insure that it adds the placeholders :) sorry I will soon make another tutorial of this feature to more fully explain how things work... So open the component and set the switch [Custom Code Placeholders] to yes... There is a new more stable version coming out soon, the version you are on is already WIN ready as you see the line breaks are working now...

mwweb commented

2017-02-12 18:09:57 +00:00

Ah. Got it. I was looking for that in the parameters, but didn't see it. I didn't think to look at the component settings, as generally don't need to go in there to make changes now that views have been added. It would be good to understand some of the different options being added. Not necessarily a video tutorial, but it could even go in as a WIKI. I see that you just added Use View Version & Date to the component as well.

Llewellyn commented

2019-07-28 22:03:41 +00:00

@gruz we just added the complete feature the exact way you originally asked for Roundtrip development #451 sorry it took so long. Yes we have had the custom-code import option since this issue was resolved, but now we also have the option to in the IDE edit the code that was place in the a GUI field, and then upon compilation it writes the changes made in the IDE surrounding that codeblock back to the GUI/table of JCB.

These options are truly some of the bests features in JCB!! Thank you for your continues support!!

@gruz we just added the complete feature the exact way you originally asked for Roundtrip development #451 sorry it took so long. Yes we have had the custom-code import option since this issue was resolved, but now we also have the option to in the IDE edit the code that was place in the a GUI field, and then upon compilation it writes the changes made in the IDE surrounding that codeblock back to the GUI/table of JCB. These options are truly some of the bests features in JCB!! Thank you for your continues support!!

Automatic import of custom code during compilation #37

I have a few questions that you can give me your feedback on.