inmarket

The new flag GWIN_FRAME_KEEPONCLOSE will now prevent destruction of the frame when the close button is pressed. Note that this flag does not hide the frame - the user application will need to trap the CLOSE event and manually set the frame to invisible. The flag just prevents the frame window from being destroyed. This is now in the repository.

Yes. If it is not destroyed then the contents of list boxes etc will be retained. It should probably be easy enough for us to add a new flag to the existing flags in the create call to control whether it gets hidden or destroyed on closure. The default would be destruction in order to match existing behaviour of the frame and setting the new flag would change the behaviour to hide it instead.

Yes, stack size is an important issue with any gui window system. For ugfx there are two stack sizes that are important... The main thread (or any other drawing thread) stack. The gtimer thread stack size. If either is too small all sorts of strange things happen.

The defines controlling GWIN redrawing all start with GWIN_REDRAW_... Please see api.ugfx.org for the full gory details.

Change the frame address will not help at all. In fact it will slow the whole operation as it increases the amount of video RAM writing that has to occur - whether by CPU or by DMA2D. Steps 2, 3, 4 from below are fine - ignore the rest. Note that setting the page container to invisible and then visible again will automatically redraw everything. No need to explicitly add redraw calls. The call you want is gwinSetDefaultStyle(). Documentation can be found at http://api.ugfx.org/group___widget.html#gae7a414480b2c34040746ca897a189b70.

If you are manually setting the style on each control this will cause each control and each child control (if the control is a container) to redraw. If you then set the style on the children as well that will cause the children to redraw again. Thus child controls are being redrawn multiple times, once for each level of parent containers it has to go through. There are a number of strategies that may reduce this redrawing... If you look at the documentation for gwinSetStyle you will see there is the option to set the global style and whether to ripple it to all controls. Doing this may result in less redraw (and much simpler code) than enumerating each control to set the style. Make your parent container (such as the page container) invisible first, set the style's on everything, then make it visible again. For a page container this would have the effect of clearing the screen (as you make the page invisible) and then redrawing all objects once in the new style (when you make the page visible again). Advanced Technique - Look very carefully at the redraw strategy you have GWIN set to. These are set using defines in your gfxconf.h. By default GWIN uses a combination of synchronous and asynchronous redrawing which provides the best strategy and least RAM and stack usage in normal situations. Synchronous redraws are immediate but use a huge amount of stack. Asynchronous redraws add latency to redrawing but allow collapsing of multiple redraw requests. In your circumstance, a more asynchronous strategy is going to be best as multiple redraw requests will be effectively collapsed in a single redraw attempt on each control. I also suspect that in your case you are pushing the bandwidth availability of the SRAM bus on your STM32 processor due to the size of your screen. This probably lowers the available bandwidth to the SRAM for CPU access. Remember for redrawing you currently have 3 or 4 sources of bus utilisation... The video controller reading the ram for display on the LCD. Because of the dual layer nature of the LTDC controller this could be multiplied by 2. The DMA2D graphics accelerator writing data into the RAM The CPU directly writing into the RAM in order to update the display RAM Any other access to the RAM chip for other application purposes eg offline image caching etc

You will need to stop updating the underlying widgets while the frame is visible as the ugfx window manager does not handle overlapping widgets except in a parent container/child relationship. With regard to the destruction of the frame - I am currently thinking that that might be the incorrect action for the frame to take. Perhaps it should only automatically become invisible on the close button being pressed. What do the community think about this?

The reason is that snprintf is pulling in the full fileio interface. Not only is this huge (both code and ram), it also causes these sorts of strange errors. It is probably a good idea to replace snprintf with the ugfx library equivalent snprintg from the GFILE module. The implementation is much smaller and will resolve these dorts of link errors. If studio is adding calls to snprintf then please list this as a bug in the studio forum.

Adding the _sbrk routine is not the best way to handle that missing symbol. In fact it incorrectly allocates an area that might be non-contiguous with previous allocations. The _sbrk symbol becomes undefined when a routine (often in the c runtime library) calls malloc. The correct way to fix this problem is to define the GFX_EMULATE_MALLOC define in your gfxconf.h. Thats causes ugfx to create its own malloc and free calls which stops the missing references the correct way.

The reason ugfx polls rather than using interrupts is because we are yet to find a chip where the interrupt works properly! Problems we have seen... 1. Some chips don't send a release interrupt thus you never get a touch up except by polling anyway. 2. Some chips only sometimes provide a release interrupt. 3. Some corrupt the reading when they raise the interrupt. 4. Some will work ok for a while and then freeze up. Only a full power reset fixes the problem (not even a software or pin reset works) 5. Some with fifo's only interrupt when the fifo reaches a particular level which means short events can be lost. 6. Some chips will flood their fifo's in the time it takes to raise the interrupt. 7. For all chips you are relying on what the controller considers a touch. Our software level detection is MUCH better than the simple method these hardware interrupts use. In general, they just don't work reliably. That however doesnt mean there isn't a chip where they do work, just that we haven't found one yet.

Looks ok to me too.

Things are a bit more complex than that unfortunately. The addition of a 2nd display completely changed the way a video driver is hooked into the system. The reason for that is there are performance and speed penalties for multiple display support and the system calculates the optimal configuration to minimise those penalties. The system of #defines used to make all this happen just do not work with single file make. If you want to try, not only will pixmaps need to be compiled seperately but also gdisp.c Try that. It might get you closer.

Tsk tsk tsk.

I think you are using a bad make executable. You need to use one that is gnu compatible. Both the cygwin system and the mingw system produce suitable make executables. Our preference is for the mingw version because of some cygwin strange pathing problems. Our makefile is designed to use either. You are probably using the old msdos make which is too simple for this type of project. The other possibility is that you have spaces in one of your path variables in the makefile. This is a no-no due to inadequacies in the gnu make. Once you have sorted out the make executable on your path you will need to change those \'s back into /'s

Let me reiterate what Tectu said earlier - the best place to start is with the example project in /boards/base/stm32f429-discovery/example_chibios3 directory. It should work out of the box with your board. If you are having trouble with SPI5 under chibios have a look in the halconf.h or mcuconf.h and similiar chibios configuration files.

This is caused by the single file make used by the arduino port. The single file make doesn't support some of the more advanced ugfx library features yet such as multiple displays. Unfortunately pixmaps internally use multiple display support. The solution is that instead of just including the one file ugfx_mk.c into the project, each of the source files needs to be included like the traditional makefile method of building ugfx. This is something we will eventually fix but it is currently low on our priority order as there is another way of building (albiet a more complex method) that does work for this feature.

Rather than calling that routine directly you need to register it as the draw routine for that progress bar. The system will then use that routine to draw it for you whenever anything changes. You register the draw routine you want and the new image parameter using gwinSetCustomDraw ()

The reason is simple, most small micros have more rom space than ram space. Ram is a more presious resource.

That error nessage normally indicates that the necessary dll's are not available. The dll's in the windows binary directory in the repository need to be in the same directory as the executable when you run it. I will retest the windows binary just to make sure later.

Thank you for that. We will go through those warnings and try to resolve them. I will also investigate why you are getting that warning to do with the anti-alias support. It might (or might not) be related to the compiler. Either way we will sort it out in the next few days and then add that compiler to the supported list. In the mean time your code should still work

We thank you for using ugfx. We love to get feedback. Ugfx is a spare time hobby for us. Most of our time is spent on earning money for our families or in full time study. I was just being cheaky with the donation comment. Part of my naughty Australian sense of humour. For commercial usage and larger companies it is sometimes worth them paying money to speed a particular area of interest for them. For mere normal people like us however we know something like that is not possible. We release the source code and make it free for non-commercial use for exactly that reason. I will look later at your patch and if i think it adds benefit to the whole community and is consistant with the design aims then i will add it. Regardless of whether we do add it or not, we really appreciate your contribution. It is from contributions such as yours that give us ideas and help ugfx progress. With regard to point 6, the gui has been written very carefully so this is not a problem. The detail is even more complex than the short description provided previously, it is enough to say that part of the design has been very carefully considered and reviewed.

On that note - I'm sure a nice donation of a few thousand dollars would enable Tectu to spend a lot more time on Studio and advance its capability very quickly.

Having Studio get to the stage of something like Delphi is really what a lot of users would like and we will (eventually) get there. Delphi in my mind was one of the best development platforms that ever existed so I know exactly why you suggest that as the example. Having studio with that sort of functionality would be fantastic but is definitely a long term goal. Having common events (such as click) across all widgets however is not feasible. A lot of people forget that this is an embedded system and its design criteria are very different to desktop style GUI's. The issue in this case is two-fold... To have every widget support a click event code would need to be added to every widget to generate that event. This seriously increases code bloat (much more than supporting custom draw routines). It can't be handled in common code for the 2nd reason below. The event stack in ugfx only allows for a single event to be handled and processed at a time per listener. This is because more arbitrary queuing requires memory allocation of each queue item. This is a speed and ram size problem for an embedded system. It also makes a part of the base GUI non-static allocable which is breaking one of the major design criteria for ugfx. Because of this limitation - if a general click event was generated for say a slider, that slider would not be able to send a new position event as the listener's event slot would already be full with the click event. If the processing was the other way around (click events generated after any widget specific events) you would have strange situations where click events seem to magically disappear - again because the listener's event slot is full. Remember that ugfx works on all sorts of platforms particularly with respect to multi-thread capabilities. Some do not support multi-threading at all (although we internally then create a co-operative threading system for them). So, generic events just don't work very well on a system designed for embedded use. The code could be added to change the event system but that would make ugfx unsuitable for a lot of platforms and applications that is it currently very suitable for. I hope that helps you understand some of the basics as to why ugfx is the way it is. The design concepts associated with a GUI on these types of platforms is VERY complex with all sorts of trade-offs between functionality, code complexity and RAM usage.

Yes you can have all you want that way however studio support is very rudimentary for the more powerful and complex ugfx features. The reason for this is two fold... a) studio was originally designed as a gui layout assistance tool. It was always expected that people would just use that to get an initial layout and would then manually edit the code to build their application. Over the course of the beta for studio users have made it clear they want more than that - something much more powerful than an initial layout tool. Unfortunately that extra power will be a while coming yet. b) studio is still very much beta. There is still lots of stuff missing even for just a layout tool.

Benchmarks are tricky because they only apply for a particular hardware platform. A different platform can give very different results. We have optimised ugfx to perform best on the types of lcd controllers found in embedded platforms, with minimal ram and tiny code. We believe that we are industry leading in that arena due to our unique video driver interface and highly optimised primitive drawing routines. Running on a desktop emulator however our performance is only average and even poor on some (Linux with X11). That is not important however as that platform is only used as a emulation platform. Any real application for that platform would use X11 directly or ugfx with the linux framebuffer driver. Having said all that, there is a video in the demos section of tbe ugfx website that shows the blistering performance ugfx can obtain on a real embedded device. That demo is old, platforms auch as stm32f4-discovery and f7 discovery with modern ugfx code should be significantly faster again.