Build a header file instead of .ino

[DynamicLoader]

Describe the solution you'd like When I want to make a page with many things on it,it builded a big .ino file.It's not easy to add my function.So I think If it can make a .h or .hpp instead of .ino,it will be better.

Thanks.

[Pconti31]

I have looked at this before. It was discussed back in GUIslice issue #79 while in beta.

You are not the first to complain about this issue and I have faced it myself.

The problem I see is that almost everything requires edits to be made when you get to customizing your application. Even storage may need editing if you add a UI element to your App that isn't supported by the Builder, such as GUIslice's XGlowball, or my custom elements that I use from my fork of GUIslice. And of course, every callback generally needs code injections.

Now you would be required to make edits to your new Builder header file and your app. I'm not sure that is a win. Nevertheless, I have received enough complaints that I'm willing to take another look at this.

In the meantime, If you or someone else in the community have features they would like to add. Contributions of code are always welcome. Feel free to fork the repository, and make a pull request with the new code.

Paul--

[Pconti31]

I reopened this because a number of people have complained about this so I built a prototype that I'm debugging now. The problem isn't generating the header for new projects.
I finished that in 10 minutes.

My prototype generates all code inside GUIslice_gen.h but one problem I found quickily is that our callbacks can't reference globals defined inside the *.ino file from the header.

Example: defining bool m_bQuit = false; can't be accessed from the button callback if the callback exists in the header. So, another thought is keep callbacks inside the *.ino file. This way you would generally never need to edit the GUIslice_gen.h file. Any thoughts on this approach?

Naming I'm still not sure of. I have been naming the header simply as GUIslice_gen.h but I have been considering naming it whatever your project name is .h but if existing projects are already using that name it would screw them up.

The harder problem is taking an existing project's .ino or .c and breaking it into two pieces and allowing updates from there. A further complication is very old projects built with beta versions of the builder are missing tags so they need to be added.

Also, I don't have Raspberry PI and display so can't test the linux versions. Not sure a header will work with a C program. I'm considering using a .cpp extension instead of .c or simply keeping a single file for linux and not generating a header version. Again any thoughts? Paul--

[DynamicLoader]

In fact,when we compile .ino,the precompiler will change the ".ino" to ".ino.cpp".Because of this,we can't reference globals,unless we use "extern" keyword.

My thought is:

[project_name].ino ---include---> [project_name]_GUI.h <---include--- [project_name]_GUI.cpp/.c

Put all GUIslice globals into the header file(including function definition),and put all function implementations into the .cpp/.c file.

By this way,we can access globals and functions in the .cpp/.c files from .ino file.

BTW:We can add a textbox in builder so users can input the name of GUIslice page header file and .cpp/.c file.If it's empty,then use default name.

[Pconti31]

My current thinking is to create the header and name it as you recommend [project_name]_GUI.h My prototype will then place everything but callbacks inside this new header. This includes GUIslice API storage globals, Saved Element Refs, InitGUI, and any startup calls.

The projects people have sent me seem easier to deal with this way, since Beginner C programmers (which Arduino attracts in large numbers) will better understand that they don't need to edit the header file and can make all changes to the *.ino file.

This allows them to add their own globals variables to a *.ino file and reference them inside the callbacks without needing to understand when to use extern. And of course, they can then directly reference Saved ElementRefs and anything else the Builder generated inside the header file without an extern.

Also, I'm seriously considering leaving the raspberry pi linux target as a [project_name].c file and not generating a header for them since I can't test proper. Even if I do decide to split up the Linux target platform files I'd most likely do it in a later release to reduce my support overhead.

I hope to give Calvin some prototype files today to get some feedback from him.

If you want to test the prototype builder send me an email and I'll send you a download link once I finish debugging. My email address is public in my github profile.

Paul--

[Pconti31]

Sorry, closing was an accident! Paul--

[Pconti31]

Fixed in release 0.13.b021 Paul--