inmarket

Those changes have been put back into the repository. I also removes the Portrait and Landscape orientation cases as they are handled automaticly by the higher level code. I have also added your board file to the boards/addons/gdisp directory. Thank-you.

Good catch. It is now fixed in the repository. There are two cases for the close - one with GWIN_BUTTON_LAZY_RELEASE and one without. In one case it was using the wrong destroy routine which would have caused the lockup, in the other it wasn't sending the close event. The close event MUST be sent before the destroy because the send code accesses the structure to get the tag to put into the event. You are right, line 312 was a typo and has also been fixed. Thanks.

This has now been fixed and a GEVENT_GWIN_CLOSE event is now sent. Because I have changed the structure slightly for GWIN events you may have some small changes to make in your code. Basically pe->button, pe->slider, pe->frame, pe->list etc have all been renamed to pe->gwin (being the handle of the window creating the event). All GWIN event structures now have the same "type", "gwin" and "tag" elements.

Thank you for this great work. We will add it to the master repository.

I will re-add this event for you asap. I am thinking of adding events for all gwin significant opens such open, close, resize. Now might be the time to do it.

This bug has been found and now fixed.

The c standard says that undefined macro variables if used in an expression will evaluate as 0. Not all compilers always follow the rules though. Try... #if defined (var) && var == 8

Write the save routine to output the data to a debug console in binary hex. You will then be able to read the results and potentially hard code them into your load routine. Note the data is binary not text and may contain as ascii null characters.

General anti-aliasing is a hard thing. With some displays it is actually impossible. Anti-aliasing requires knowing the surrounding pixel values. If a display has no read back capability this obviously cannot happen. With text anti-aliasing on these types of displays we can still anti-alia but only if we are also filing the background. So, any general anti-aliasing support will only ever be possible on certain types of display. This is the primary reason it had been low priority for us. There is just so much else to do.

Send us your board file and/or the link to your repository and I will add it ti the official ugfx repository as either a full board definition or in the boards/addons directory. It is a pleasure to help where we can. Well done on getting it going.

It is pretty hard to tell from the video however it appears it might be a problem with the back-light or with the display not being driven. Close visual inspection might help you determine which is happening. For a back-light issue: At reset it appears the backlight turns full on and then partially fades out leaving horizontal bars. Check the black-light is set to 100% and this is done as a solid logic level drive rather than a PWM signal. A PWM signal to the back-light at too high a frequency might cause this behaviour. If it is definitely the backlight but not a PWM issue then there is a hardware fault with the LCD panel. If it is not the back-light: It appears as if the display might not being driven at all. That explains the "fade" affect as the capacitance on the display charges or discharges. Perhaps the display is still in the "OFF" state or the address you are using to talk to the display is incorrect. Check the board file for the display matches your physical display connection. Double check that the display controller is what you think it is and that it matches the driver you are using. There are many E-Bay purchased displays that are mis-labeled with regard to their controller chip. Also, because physical line length to the display significantly affects timing, use the shortest possible connections between the display and your board. In your board file also choose the most conservative timings possible at least until you have the display operational. Hope that helps.

The rawrtos code has been added to the repository. There were a couple of minor changes made to the code for compatibility with other platforms so can you please test it to make sure I haven't broken anything? For the helper2416 board, in your code parts of the mouse and video drivers have been located in routines outside the uGFX framework. Whilst this is fine for the video driver as it is localised to the hardware specific board file, I will have to think about how to integrate the mouse driver so that uGFX driver can be stand-alone but still allow you to share part of the driver code with systems outside of uGFX. I should get this done over the next week or so. Many thanks for your great work.

If using consecutive tag values starting from 1, 0 as the do nothing case works well as the compiler should generate a switch jump table where 0 is the first element of that table thus leading to the most efficient code (no table offsets to add by the compiler).

Wow, that is fantastic work! Over the next few days we will look through the code and integrate the important bits back into our official master repository so that raw-os becomes a fully supported platform.

Getting round this behaviour is difficult and relies on "error" values. It is easier to assume that 0 is that error value. It correspond nicely to an default initialised init structure. As the user sets tag values there is no reason that zero is any worse an error value than any other and there are a number of implemtation reasons why it makes a good one in this situation.

All timing functions in ugfx use real time milliseconds or microseconds. This is because ugfx is designed to be operating system neutral. MS2ST is a chibios specific call. Some operating systems don't even have the concept of a "tick". Even chibios V3 is "tickless" with ticks only being maintained as a optional scheduler quantum and for V2 compatibility. I will run some tests over the next few days to see why geventEventWait might be returning early.

Yes that is exactly what will happen when I get round to creating those functions. The vmt routines will be exported to proper api calls. In the mean time the method described in the above post will always allow the border sizes to be determined.

Some of the better known development boards have sets of board files predefined for them. You can find those in the boards/base directory. Some extra board files for various situations have also been put in the boards/addons directory. If you are lucky you will find exactly what you are looking for in one of those two places.

I thought creating the window you specify the internal size already but I might be wrong about that. If not, in the interim you can create the window invisible, get its internal size and then resize the window (now supported but not well tested) before making it visible. Later I will look at what is required to return border sizes etc. Note the above method is the defined/preferred way of doing it under win32

I think you are both missing the point. The driver is either calibrated and clipped or non - calibrated with raw readings. The touch driver test code uses this to enable testing of the touch parameters. If however you disable all calibration code this is NOT the same as running in the special raw mode used by the touch driver test tool. In this situation you will be getting raw readings but they will be clipped to the screen dimensions. As the touch scale is not likely to match one to one with pixel display scale this means the readings will not scale over the display and of course widgets will not work. In other words this touch controller cannot operate without calibration or atleast scaling of its readings. One that does is the Win32 touch driver as windows performs the scaling and clipping for you before passing them to the ugfx driver. Effectively mouse/touch scaling as seen at the driver level corresponds one to one with the display scaling. If you want to manually control the calibration and scaling then you need to use Tectu's method with calibration turned on but replace the 1's with the hardwired scaling factor. This will prevent the user being prompted for the calibration. Note also many touch panels are oriented transverse the the display orientation. If your panel is one of these calibration is the only reliable way to get a working translation and scaling matrix. The maths involved in doing it by hand are nasty.

If you want after 500ms the 2nd parameter should 500 not MS2ST(500) as geventEventWait takes milliseconds as the 2nd parameter. Try that change first and let us know if that works. I know there were bugs around that area in the old code. If the new code does not work after the above change let us know and I will do some tests.

Check your make script and your linker script. gfxInit is a public function so if it is undefined it must be a linking problem.

Internally we do something like this already. It should be simple to export this in some form. I think when you specify a size on creation of the frame you are specifying the internal size. I will need to double check this.

True - For list pointers, menu scrolling and that sort of thing the toggle model is best.

Just "on" toggles - that makes sense. It would also be easier to implement than on with intermediate off's. I can't remember the exact context of "role". I will examine the source and get back to you on that one. I think it might refer to when a slider for example can have two toggle inputs attached to it. One has the role of an up button and one has the role of a down button. If you are talking about a rotary encoder incrementing or decrement in a counter - that is exactly what the dial interface is. An analogue dial is only one way to do that. In this case the rotary encoder is used to increment and decrement the counter "dial" value. The application gets notifications as the counter/dial value changes. The current slider widget can be connected to a dial input now and it will do what you are suggesting. I don't think a progressbar has that dial input hook yet. A rotary equivalent to a slider widget would also make a great widget. what defines a "dial" is something that can move in value between a minimum value (usually 0) and some maximum value. How that value is physically changed just depends on the driver eg analogue dial, rotary encoder, temperature sensor, possibly one axis of an accelerometer, a light sensor etc. Digital or analogue doesn't matter.