inmarket

Two new functions have been added to the GWIN List. The first function gwinListSetSelected() enables an item in the list to be selected or de-selected via the API. The second function gwinListViewItem() scrolls the list to ensure that a particular item is currently visible in the list

Now added to the repository (but altered slightly)

That will make a very worthwhile addition to the list. I will integrate it into the master.

A superfluous forward definition for struct GContainerObject has been removed. Whilst this should be ignored by compilers as the forward struct definition and a subsequent typedef are equivalent objects, some versions of GCC incorrectly flag a compile error (but seemingly only with some combinations of compiler flags). The superfluous definition has been removed to prevent this incorrect compile error.

Dynamic sized labels may crash if the text in the label is changed at run-time. It doesn't always happen as it requires a particular set of timing and positioning circumstances for it to occur. A work-around has been added to prevent the crash. The work-around prevents a dynamic sized label becoming smaller in order to avoid the circumstances leading to the crash. The dynamic sizing will still allow the label to grow larger. A complete fix will be attempted at some time in the future.

I have found a reasonably simple workaround for the problem so dynamic sizing should work again with the latest master repository. The caveat is that a dynamically sized label will only increase in size, never decrease at least until I can spend the time to fix it properly.

By the way - nice demo.

I have found the problem... I used the dial demo you attached to debug however I am sure that the problem is likely to be the same in the button demo. First the workaround... wi.g.width = 40; // Used to be wi.g.width = 0; wi.g.height = 20; // Used to be wi.g.height = 0; ghLabel = gwinLabelCreate(0, &wi); The widget has this nice little feature whereby it can auto-size based on the text that is in the widget. It is the only widget that supports this functionality and was at the time just an after-thought. This functionality is perfect for a static label but when the text changes at run-time it tries to resize the widget during the label's redraw function. Unfortunately due to changes in the redraw handler since this widget was originally written, this causes the widget to recursively redraw in certain conditions thus causing the hang leading to stack depletion some time later with its associated kernel inspired crash. This is likely to be tricky to fix so the work-around currently is to use a fixed size label as seen above. I will look at this in much more detail when I get some more time. Unfortunately you can tell by my slowness in getting to this that real work has been keeping me very busy. For now it will be considered a known bug.

This is now fixed in the master repository

I have had my first look at it. Please change your OPT_CPU to x32 rather than x64. x64 has not been tested for reliability and really is not needed for an embedded system emulator. There is a very good chance there are some 64 bit problems in the library. Both x32 and x64 should run on a 64 bit Linux machine. If your compiler complains about compiling x32 on your 64 bit machine it might be because you have not installed the 32 bit libraries for your C compiler. Each Linux distribution has a different process for doing this, some include the libraries out of the box. If you have trouble with this let us know what distribution you are running and we will see if we can google the proper install command line. I have not tried a compile yet - that is just what struck me when I looked at it first.

I should be able to look at this now within about 24 hours. I will report back as soon as I have any results for you.

If nothing is being shown with a particular font then this is an ideal place to start debugging. The primary advantage of prototyping using a desktop operating system like linux or windows is that you can use the ide debugger and thus more easily debug your application. With regard to multi threading, this is required by any windowing system except the most rudimentary simply by the nature of what you are doing. As mentioned before it is the input system that requires the multi-threading not so much the drawing. Whilst I have ideas to remove that requirement it is not an easy task. Linux and win32 emulations have been well tested, win32 probably more than linux. I would be surprised if there was a significant issue in that area simply as for the reasons above it is these two platforms that most of the gwin system was written on. That is why I was looking at possible compiler flag issues as we don't seem to be seeing the same problem. Can you please write a test demo (something like one of the demos in ugfx) that demonstrates the problem - the simpler the better. We can then compile the same program and see if we get the same result. If we do we have something to debug, if not then we know it is something about your build environment.

With regard to the initial dynamic allocation of the text from the init structure, if this is a problem pass null initially and then use gwinSetText afterwards to set the text with FALSE for the last parameter.

Sorry i missed the static on the variable definition. I however just noticed you are compiling under linux. Are you compiling using the thread safe c runtime library? I think the compile flag is gcc -pthread but please check the doco first. This flag needs to be specified as well as including the pthread library. Alternatively try compiling with our make system which (should) get it right.

The problem I think is with the last parameter to gwinSetText. This last parameter tells the function whether to copy the string because it is not a static string. As your buffer is allocated on the stack you should be using TRUE for that parameter. You might also want to look at using the snprintg function provided by ugfx. Using it instead of snprintf should compile a lot smaller as the whole stdio package from your standard library doesn't need to be included. Stdio is usually quite big.

Fantastic. When my display arrives I will know what to do.

I have not had time yet unfortunately. Work has been extremely busy. There has however been something else that has come up that may be an issue... Try using GOS_RAW32_HEAP_SIZE to invoke the use of the raw32 memory allocator. Some third party (including ones like the arduino versions) cannot handle being called with a non - native stack base and thereby cause the application to crash in unexpected places. If that doesn't work please let me know and I will make a bigger effort to allocate that time I promised.

Not sure why the axis and grid are not being displayed without the clear first - they used to. This is a very old demo however and has not been checked in a long time so I will debug to see what is happening when I get a moment. Theoretically as the screen is already clear it shouldn't be necessary to clear it again. I suspect some of the widget flags are no longer being initialised correctly. Glad you found a work around in the mean time.

Yes a pointer to a pre allocated object can be passed to the widget constructor. It is indeed designed for smaller memory systems that need to very carefully control memory allocation. It also saves the memory allocator overhead. Similarly widget strings can be passed in as static strings or copied to dynamic memory. There are however some strings that are always dynamic for example list box strings. Widgets such as the image widget also use dynamic memory for things like image decoding. Thus most widgets can avoid dynamic memory allocation with careful programming - but not everything. Whenever dynamic memory is required the system always uses gfxAlloc and gfxFree. These are implemented by the gos layer and should be able to be called safely anywhere in the gfx code. In your case however the arduino malloc and free do not operate correctly unless the code is running on the native stack. This is a bug in that implementation but is not infrequent in embedded libraries. One bad implementation gets replicated into lots of platforms. It is for the lack of good memory allocation routines that the alternative raw32 memory allocator was written. It solves that problem nicely fixing those platforms that have no suitable routines and those that are buggy (such as the arduino library version). I can't complain too much about their implementation however as changing the stack is not a common operation and so it is highly unlikely that situation has been tested well by the arduino library writers.

Compare the label padding to the number of pixels you are moving the label.

Depending on the justification specified. Left will put it hard left, center will put it in the middle (plus or minus a pixel because of rounding) and right puts it hard right subject to inter - character spacing.

Just a thought... If you put a space at the beginning of the label it may remove this problem. It could be caused by the font being hard up against the left edge of the label but the right edge may have a single pixel space due to inter - character gaps as defined by the font.

I don't know. Some debugging of the move redrawing would probably be required to find out.

Very nice project and a great demo of a custom widget. Well done!

Very nice video!