tubbutec Posted June 4, 2016 Report Share Posted June 4, 2016 Hi, when writing extensions to ugfx - be it a custom draw routine, or a new gdisp function - I often encountered the following problem. Usually I would put my own code into separate files and not touch the ugfx code at all. This allows to easily update ugfx, while all the custom stuff remains untouched. I believe this is the intended behaviour. However in the functions I write I often would like to access functions which already exist in ugfx, but are declared static so it is not accessible from outside the file. Copying these functions and place them in my own file seems to be wasteful. I wonder what the recommended procedure is in such a case? For example in my gdispGFillStringBoxAutoScale function (see other thread) I needed to access functions from gdisp.c and gdisp_fonts.c. An other example is a custom draw routine for gwinSlider which uses SliderCalcPosFromDPos I came up with different solutions, but they all require a modification of the ugfx source. But maybe there is an obvious way I did not think about? 1) Remove 'static' from the original code and access the function with 'external' 2) Place an include hook at the end of all ugfx files. Here the user can include additional files which are then in scope of the ugfx file. This however does not allow to use functions from different ugfx flies.. thanks a lot ! Link to comment Share on other sites More sharing options...
inmarket Posted June 5, 2016 Report Share Posted June 5, 2016 In any decent sized system like uGFX there will always be internal functions that someone eventually wants to use to extend the functionality. On one hand we want to keep support functions private (static) to avoid cluttering the api and to prevent misuse but on the other hand sometimes those functions are useful to someone else. There is no perfect solution. When this occurs code must either be copied or the original code modified (which makes upgrading more difficult). For your new gdisp function adding it to gdisp.c would appear to be the correct solution. I am currently in the phase of playing with api and build structures for ugfx v3. It has given me the opportunity to re-examine decisions made in the past. As part of that, the problem you are describing may go away as i am planning to add an "extension/plugin" facility that would enable you to add and test new core functionality without modifying the ugfx code itself (in most cases). Stay tuned for more details over the next few months on ugfx v3. Link to comment Share on other sites More sharing options...
tubbutec Posted June 5, 2016 Author Report Share Posted June 5, 2016 that sounds promising, thanks a lot! Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now