Jump to content

Recommended Posts

Posted

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 !

Posted

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.

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...