This PR changes how the Image List file is generated, and how images are loaded with or without the existence of an Image File.
No Images List file
wxueImage() and wxueBundleSVG() will be generated in any file that needs them whether or not that file actually contains the image data array. A conditional is now used to mark the functions as inline if compiling under C++17 or later, or static if compiling under C++14 or earlier. For C++17, only one copy of the function will be linked into the executable, and for older compilers that static will prevent name conflicts, though it does mean the function body will be added multiple times to the executable.
Each image data array is still unique to the project, and where it gets defined still depends on the order of the forms in the project. Each form's generated source file will have externs declared for any image that is needed. These are no longer generated in the header file, since the file containing the image definition could change any time the user changes form position.
Images List file
The wxueImage() and wxueBundleSVG() functions have been removed from this file. In their place are get_image() and get_bundle_svg() which are within the wxue_img namespace. Normally, these will not be used by a dev, since there are both bundle_...() and image_...() functions for loading any image added to the list that can be loaded into a wxBitmapBundle or wxImage.
By default, the header file only contains the namespace and all of the available functions. A add_extern property has been added to the Images List node -- and if checked, extern declarations will be added to the header file after all of the function declarations.
wxWidgets 3.1 code generation
This is still broken around images, and this PR probably makes it worse. A second branch is active with 3.1 code generation fixes, and after this PR is merged into it, work will continue on that branch. Chances are, if you mark your project as using wxWidgets 3.1, you will not be able to compile it.
This PR changes how the Image List file is generated, and how images are loaded with or without the existence of an Image File.
No Images List file
wxueImage() and wxueBundleSVG() will be generated in any file that needs them whether or not that file actually contains the image data array. A conditional is now used to mark the functions as
inlineif compiling under C++17 or later, orstaticif compiling under C++14 or earlier. For C++17, only one copy of the function will be linked into the executable, and for older compilers thatstaticwill prevent name conflicts, though it does mean the function body will be added multiple times to the executable.Each image data array is still unique to the project, and where it gets defined still depends on the order of the forms in the project. Each form's generated source file will have
externsdeclared for any image that is needed. These are no longer generated in the header file, since the file containing the image definition could change any time the user changes form position.Images List file
The wxueImage() and wxueBundleSVG() functions have been removed from this file. In their place are get_image() and get_bundle_svg() which are within the
wxue_imgnamespace. Normally, these will not be used by a dev, since there are bothbundle_...()andimage_...()functions for loading any image added to the list that can be loaded into a wxBitmapBundle or wxImage.By default, the header file only contains the namespace and all of the available functions. A
add_externproperty has been added to the Images List node -- and if checked,externdeclarations will be added to the header file after all of the function declarations.wxWidgets 3.1 code generation
This is still broken around images, and this PR probably makes it worse. A second branch is active with 3.1 code generation fixes, and after this PR is merged into it, work will continue on that branch. Chances are, if you mark your project as using wxWidgets 3.1, you will not be able to compile it.