Jump to content

All Activity

This stream auto-updates

  1. Yesterday
  2. The gdisp_lld_blit_area() function is broken in a few ways, both to do with blits whose source X coordinate is non-zero: 1. The following line is intended to compute the source array for the blit operation, but doesn't take into account the source offset. buffer += g->p.x2*g->p.y1; It should be changed to something like: buffer += g->p.x2 * g->p.y1 + g->p.x1; 2. Near the bottom of the function, the following code is intended to detect if a rotation has been done (thereby changing the buffer variable from the pixmap base buffer to a freshly allocated, rotated
  3. uriy

    Multiline textedit

    I think their reason was to save time and implement it as is right now from the box. Be honest collaboration like that is interest for me, but right now I have not enough time. I hope to return to that later.
  4. I haven't had time to check out your code yet - just the video. Looking good! What was their reasoning that it wouldn't be possible? if you like we might be able to improve this together and eventually put it into the official µGFX library so it's supported out-of-the-box
  5. uriy

    Multiline textedit

    I did some work. Maybe it will usefull for somebody, you can find sources here https://bitbucket.org/only_uriy/ugfx_multiline/src/master/ There is new widget multilinetextedit. It's not completed, cursor is not redrawing at mouse click position. And there are other several prerequisites, which make it not ready to use by all. My aim was to show for other persons that it's possible to do. Because thay told before it's impossible. In attachements you can find main.c for test project and video how it looks. 783700217_Untitled14.avi TestProject.7z
  6. Last week
  7. For paid support options/discussions, please contact us via e-mail: info@ugfx.io
  8. uriy

    Multiline textedit

    What is price for that and estimated time?
  9. Hi! As you stated the existing text edit widget only allows for one line of text. The proper way of doing this is creating a new widget called MultilineTextedit and implement the functionality. It might make sense to use the exsting Textedit widget as a base for this (i.e. copy-paste & modify). Other than the API documentation you can find documentation on creating your own widget here: https://wiki.ugfx.io/index.php/Creating_a_widget Alternatively we can implement the widget for via paid support.
  10. We are developing a device with a graphical LCD and hardware qwerty keyboard. We need the ability to enter text data up to 256 characters. At this time we use gwinTexteditCreate(); It works, we can type text and move the cursor to left and right by buttons for editing. But it allows filling only a single line of text. In a single line we can show up to 32 characters, it's a little bit inconvenient. It's possible to show on our LCD up to 4 lines of text. How to implement multiline text input with the ability to show 4 rows with 32 characters at each line and use cursor fo
  11. Earlier
  12. @inmarket Sorry to bother you again, just wondering if you had the chance to look at this yet.
  13. Sorry, I have been away and unable to respond. I will be back this coming weekend and will have a good look as soon as I can. The most likely reason is gwinPrintf is processing byte by byte rather than character by character.
  14. @inmarket are you able to reproduce this?
  15. Hello & welcome to the µGFX community! Yes that is still true. If you purchased an µGFX 2.x unlimited commercial license you can still use any 2.x release without any additional costs. This also applies if it's a new/different project or product as long as the license holder noted on the licensing document is executing the development/sale.
  16. Is this still true? We have a purchased license couple of years back and want to use uGFX in another of our products. I want to make sure that I understand the licensing before we do that.
  17. Hi @inmarket, I get the same result as before with this code: char* accented = "é"; gwinSetText(ghTitleLbl, accented, gTrue); // works, sets text to "é" gwinPrintf(ghConsole, accented); // doesn't work, prints "é"
  18. A simple way is to just add a timeout value of x seconds instead of gDelayNone. If you get a NULL response then you have a timeout and the screen can be turned off. A non-NULL response can turn the screen back on if it was off.
  19. Hmm. Without looking at the code, it looks like a utf8 encoding problem. The reason I have this suspicion is that for the label you are getting a single character output, for the console you are getting a two character output. I suspect that while the two strings look the same they are actually encoded differently. Both the console and the label use the same underlying font routines so the only way they would give different output for the same input is if perhaps the console is printing byte by byte instead of character by character or string print. Try putting the string into a vari
  20. Maybe there's a note about this somewhere, but when gwinPrintf-ing accented characters from my custom font to a console, they don't render correctly. gwinSetText works fine for labels. So for example, gwinSetText(ghLabel, "é", gFalse); // works gwinPrintf(ghConsole, "é"); // doesn't work, prints "é" Is there a way to make this work using the console widget? Thanks
  21. The FT6x06 driver was contributed by a community member. It's likely that not everything in there is optional. We welcome any kind of contribution to improve the state of community-supplied drivers
  22. After more investigation it seems the FT6x06_TOUCH_POINTS register on my display is initialized to 0xFF instead of 0x00 as on the datasheet. I have modified the touch check to see if the number of touch points is valid (1 or 2)
  23. I'm using the FT6x06 driver. I discovered that when I log the coordinates read in `read_xyz`, when the app starts it detects a touch but the coordinates are x=4095 and y=-1, which don't make sense to me. I could modify the driver to check for this but perhaps it points to a problem elsewhere?
  24. What GINPUT driver are you using? This might very well be a driver "problem" (or feature). Can you reproduce the problem when you take you application code and compile it into a native Windows, Linux or MacOS application?
  25. Thanks Joel, ginputGetMouseStatus works great. However, for some reason when I first start my app, it reports that the touchscreen is pressed, until I tap it with my finger. Do you know why this would happen?
  26. Hello & welcome to the µGFX community! There are various ways of achieving this. For example, you can have a look at the /demos/applications/notepad demo which is a small paint-like application. To draw without handling the touch (mouse) inputs through widgets. Instead, it uses ginputGetMouseStatus() to retrieve the current mouse status. You can use the GTIMER module to implement the screen timeout easily.
  27. Hey there, I am wondering how I can detect any touch event, not just when touching a "pressable" widget. My goal is to turn the screen off after x seconds with no user input, then once the user touches the screen again, for it to turn back on. My event code follows the code samples closely: // Init event listener geventListenerInit(&gl); gwinAttachListener(&gl); // ... GEvent* pe = geventEventWait(&gl, gDelayNone); if (pe != NULL) { log_debug("ui/main",
  1. Load more activity
×
×
  • Create New...