KeyWorksRW
Bug: Custom includes files are not allowed using the common syntax #include <myinclude/myfile.h>
Description:
Perhaps I'm missing something, but I noticed that wxUiEditor doesn't allow to use angle brackets to include customized files.
As I see it, it seams wrong, because all user customized class must be inserted in a relative manner using the syntax #include "../../../myinclude/myfile.h" instead of #include <myinclude/myfile.h>
Normally a programmer has got its own folders where common files (especially, for a RAD tool, customized controls) are stored and shared among different application. The common way to include such files is to use the syntax #include <myinclude/myfile.h> where the base folders are defined using compiler/IDE include directories.
Otherwise every time, for any reason, an application folder or a common library folder is moved, potentially many applications must be modified.
That's why in my opinion the following property, must be editable by user if she/he needs so.
In this example I should be able to insert <wxhControls/wxhButton.h> instead of wxhControls/wxhButton.h
Actually the generated code by wxUiEditor is #include "wxhControls/wxhButton.h" which leads in many compilation errors as the compiler is not able to find the file "wxhControls/wxhButton.h"
Such an errors can't be solved, as the user is not able to insert <wxhControls/wxhButton.h>
This wxUiEditor behaviour is weird and it should be avoided in general, and it is blocking for planning to port projects from other RAD tools.
Please take in consideration this last suggestion or both
Everything can work as it is, simply moving the "src_preamble" at the beginning of implementation file, which is, in my opinion, the right place for it, not after local includes.
Or, at least, it is necessary an option for those who uses "precompiled headers"
Put the comments in the wrong issue (#1262). The ;tldr version is that I will change imports to place the header filename in the local or system properties based on whether it uses angle brackets or quotes. I'm still thinking about what to do about the derived_header -- technically it isn't needed, since you can simply add it to the local or system form property, but it's convenient to have it in this location.
I'm sorry @KeyWorksRW, my bad, I've completely forgotten that ... I cant' wait to use wxUiEditor for all my projects :), thus I started to port all my wxFormBuilder projects without waiting for an official release.
I'm hoping to get an official release out on the 20th of this month, so this is definitely the time to be verifying that it is working correctly for you.
And just as an aside, I forgot that the derived_header property even existed -- I had to search the code base to find where I placed it. 😬
Adding this to the 1.2.2 milestone as part of a general review of how header files are handled.