eGUI experiences

leb — Mon, 16 Jan 2012 23:28:31 GMT

I'd like to post these (I hope) constructive comments re eGUI. Without a forum of its own it's hard to know if I am duplicating other's comments or even if I am posting them in the correct place. Perhaps the new version already implements them but how can I know?

1. Terminolgy. At lot of what is going on in the screen module is actually manipulating the display. By this I mean a Display is made up of one or more screens. That ties in with the next comment:

2. I think it would help if a screen is just another object like any other object. This would allow the user to create and manipulate a group of objects by creating a screen which is in the object list of a parent screen. Then the user can easily show, hide, change the scheme, etc of the group. What ends up on the display is the screen which is not in the object list of any other screen. I have done exactly this by cloning the screen code, calling it a container, and in the data putting a pointer to a new obect called a container. In the container object the data points to the new container module. I put this container object in the object list of a screen. I did not want to change the schemes, so I needed only change the D4D_GetClientToScreenPoint() and D4D_GetScreenToClientPoint() code in the original screen code to walk up the screen tree. A side benefit is that when you define the objects that will be in a group you do so relative to the container. When you move the container object around all the child objects go with it. In this model a console log is a conatiner that contains a multiline text box and a scroll bar (if wanted). A "tab control" becomes very simple to create and implement.

Re: eGUI experiences

Gargy — Thu, 01 Mar 2012 16:07:11 GMT

HI,

good point we are thinking about something similar, but we have to keep the backward compatibility and also light style of driver.

We will see.

Gargy

Other NXP ProductsのトピックeGUI experiences

eGUI experiences

Re: eGUI experiences