Search Results
Search results 381-400 of 430.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Hi Ashley, you can do that by removing the widget's effect. By default it has the 'normal' effect. C Source Code (1 line) Best regards, Florian
-
Hi Sridhar, what you want to do is give a button a custom look, if I understand you correctly? You can do this by overwriting the widget's callback function and do the custom drawing in the WM_PAINT case of the callback. Note that the bitmap you draw should have the same dimensions as your button so that it fits. C Source Code (52 lines) Best regards, Florian
-
Hi Sridhar, you have to react on that button in your program and then show your numpad window. The simplest way to show a window would be to just call WM_HideWindow() and WM_ShowWindow(). But you could also move it in and out using an animation to give it a fancier look. You can set up your own animation (see the chapter "Animations" in the manual) or use the functions GUI_MEMDEV_MoveInWindow() and GUI_MEMDEV_MoveOutWindow(), although they require a bit more memory, as these functions are using …
-
Hi Andrzej, no, rotating widgets is not possible. What you might want to do instead is changing the display orientation instead of rotating each item individually. You can do this by changing the display driver in the file LCDConf.c. Your hardware uses the Lin driver and you can find a list of available orientation settings in the manual under "33.7.6 GUIDRV_Lin". Setting the display driver to GUIDRV_LIN_OSX_32 should achieve what you need, if your color depth is 32bpp. Best regards, Florian
-
Hi Volodymyr, yes, this behavior is correct. Calling WM_SetUntouchable() to make a window untouchable means that the PID info doesn't get send to the untouchable window, but to any window behind the untouchable window that isn't marked untouchable. It's exactly how the untouchable mode for a window should work. The bottomWin was never marked untouchable, so it receives the PID info. Best regards, Florian
-
Hi Volodymyr, the error lies in line 39. It should be "Id == GUI_ID_BUTTON0" instead of "Id = GUI_ID_BUTTON0". Now you just set the Id variable and the if-clause checks if Id is not zero, so you always land in that case. A tiny but weighty error, took me a while until I saw it, too... I'd advise you to call WM_InvalidateWindow(hItem); after you set the enable/disable state of the spinbox, so it gets completely redrawn. Best regards, Florian
-
Hi Sridhar, currently emWin doesn't offer a virtual keypad, but I've attached a ready-to-use keyboard with a small sample showing how to use it. When clicking on the EDIT widget in the sample, the keyboard is opened. Alternatively, the keyboard is opened via the button in the bottom right corner of the screen. Best regards, Florian
-
Hi there, I've tried again with what you said, but I couldn't reproduce such a behavior regarding the memory. Before my first call of GUI_LANG_LoadCSVEx(), there are 253,020 free bytes, after the first call it's 214,024 bytes. And no matter how often I call GUI_LANG_LoadCSVEx() with the same array pointer as parameter, the number of free bytes stays the same. There is a function to free the memory, but it got added with emWin V5.50. By the way, when you're already using an emWin library by a ven…
-
Window
PostHi, it depends on what you like to do, you can either use one BUTTON callback for several buttons and check via the widget ID what should be drawn/done, or create a callback for each button individually to have the code separated. If these buttons are all in the same window, I would advise you to keep it all in one C file just for the sake of clarity. But, same as with the callbacks, here you're also free to decide whatever suits best for you. Quote from bio_med: “Also, what if you want to call …
-
Hi Andrzej, I'm not sure what you mean by converting, but if you mean custom drawing a widget then yes, you're able to custom draw all widgets. This is done by executing the drawing operations in a WM_PAINT case in a callback function. This function will be set to a widget using WM_SetCallback(). Here's a small sample demonstrating how to do this: C Source Code (70 lines) Best regards, Florian
-
Hi, I couldn't reproduce the error with this version either. Based on how your test went, it sounds like a memory issue. But in my test, emWin didn't run out of memory. You could still check if you run out of memory by watching the variable "GUI_ALLOC__Context", there's an element called "NumFreeBytes". If you do, that's your error, emWin needs more memory. If that still didn't solve it, I'm afraid I can't help you out any further, unless you send me a sample that I can run to reproduce your err…
-
Hi Alex, I don't think it'll be easy to implement the LISTWHEEL's behavior into your custom widget. When the LISTWHEEL was made, there was no motion support but only timers (ancient times...). Also, as you already said, you can only set the Period in WM_MOTION_INIT, not after the init. Best regards, Florian
-
Hi htsmith19, normally this happens if the y-size of the widget isn't big enough to display all the items. When this is the case, a white space is added to make up for that. And when this white space is clicked, the items move up. Note that the y-size you give the DROPDOWN widget upon creation is the y-size of only the dropdown menu that pops up, meaning only the framed box without the button to open and close. To fix this you could try to increase the y-size of the DROPDOWN widget. To calculate…