@somasundaram-i Hi!
Why is your image placed at X:80 Y:-20?
Try placing it in at X:50 and Y:50.
I will try to simulate your conditions (1280x720 resolution) and test this.
I will get back to you, meanwhile please try placing the image at the center. Also you can try using other scale modes and see what happens.
Best regards,
Kl3m3n
@Sato Hi,
try setting the RTCR parameter to a low value, e.g. 0.1. This should give you updates with an interval of 10 seconds, which should be enough for you to disable the RTC. You can even go lower, up to 100 seconds.
Note that when creating the RTC, it will give you the time immediately and then with a specified interval.
Regards,
Kl3m3n
@Sato Hi!
Yes, the localisation can be a problem.
I will fix the RTC so it will return the day of the week as a number.
@Sato said in command that returns the date and time and the day of the week:
No, it not works, the date is wrong 2025/37/13, the time is correct
Can you please provide the initialization for RTCF for this?
Thanks.
Best regards,
Kl3m3n
@Sato Yes, you were missing the '|' character.
BR,
Kl3m3n
@Sato Hi!
You can do this in the following way:
Set the format to:
"yyyy-MM-dd hh:mm:ss dddd"
The dddd part should give the days:
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday.
Create a lookup table to convert this into a number from 1 to 7.
P.S.: You can replace dddd with ddd, which will give you the short names for the days (e.g., Mon, Sun, ...).
Best regards,
Kl3m3n
@RudiP Hi!
Thanks for reporting the issue. To help diagnose the problem, could you please provide a minimal example where this happens? Specifically, I’d like to see the widget initialization code that triggers the problem.
Also, what is the make and model of your Android device? If it’s an older or lower-end device, the issue might be related to limited system resources like RAM or GPU memory. Initializing complex widgets with a lot of data can sometimes cause delays or rendering issues on such devices.
Lastly, does the app crash or freeze, or is the screen just black but still responsive to touches?
Best regards,
Kl3m3n
@Sato I am glad to hear that! 
Best regards,
Kl3m3n
Hi!
Ok, I understand!
@Sato said in On close with > clear some flags:
If Guio loses its internet connection, after a short time the Esp restarts and all the flags are cleared.
How does the ESP know to restart if GUI-O loses connection?
@Sato Hi,
which connection type are you using?
If you are using MQTT, and you have a bad connection, the "exit" action could actually take longer and the app may seem unresponsive to the user. This is not a good solution.
What do you do if GUI-O suddenly losses internet connection? How do you clear the flags then?
Kl3m3n
@Sato Hi!
I am great, thank you. What about you?
I assume you want to clear the flags on the microcontroller side? So, on your microcontroller side, just clear the flags on disconnect (Bluetooth, some USB connections).
In MQTT it's a bit trickier, but you can send periodic ping to the app (using @ping command). When there is no reply after, for example, 3 ping requests, you clear the flags.
Delaying the exit in order to send a message is not a good approach in my opinion as the app could seem unresponsive.
Best regards,
Kl3m3n
@kl3m3n The issue should now be fixed.
You will need:
Best regards,
Kl3m3n
@Fred-Neuman said in Gui-0 Live Designer V0 .0.16 - Transfer to Device:
Gui-0 Live Designer V0 .0.16 - Transfer to Device
The command “transfer to Device’ is quite useful to transfer a design toward android device:
\Android\data\com.guio.guioapp\files with the PRO version.It works fine with Widget that has no customisation (with default value) since the data sent is shorter. Although If I customize a widget with some features, it add some double quotes and backslash to the Widget parameters. In my case it prevents the Transfer to my Device Samsung. Example for Spinnable list Widget:
|TU UID:tu3 X:50 Y:50\r\n - Transfer to Device works fine
|TU UID:tu0 X:18 Y:55 FGC:#FF0000 FSZ:5 DAL:"2,3,5,7,9,11,13, "LI:2\r\n"
- Won’t transfer to Device - I suspect \” Li to be the cause
I would say that the issue occurs with others Widgets, but i did not make a test on everyone
Regards
Hi,
sorry for being quiet for so long.
I have checked this and the problem seems to be when using parameters that expect internal quotes (e.g., DAL:"2,3...").
Since the "transfer to device" feature uses the EXTF component (file read / write) of the GUI-O, the problem lies there.
I will try to fix this issue ASAP.
Best regards,
Kl3m3n
@Fred-Neuman Thanks for pointing this out! I will check this and let you know.
Best regards,
Kl3m3n
@Fred-Neuman v0.0.16 also includes this fix.
Best regards.
@Fred-Neuman Hi!
Please remove the \r\n from the end as the GUI-O designer already does this internally.
On the next release, I will fix this, so it will not matter.
Best regards,
Kl3m3n
@forest70 Hi!
I have fixed the ACT issue.
The new version should be available in Play Store in a couple of days.
Best regards,
Kl3m3n
@forest70 Hi Davor,
this seems to be a bug.
I will fix it with the next release!
Thank you for reporting this.
Best regards,
Kl3m3n
@Proto Hi!
Yes, you need a license for each Android device that uses a different Google account from the one used to purchase the license.
Licensing is based on the app, not on development. Specifically, the app does not track (and cannot enforce) which device is designated as the "development" device.
Best regards,
Kl3m3n
I decided to add an option to request the current value / state of (specific) widgets. This seems a better solution compared to sending the data on lost focus.
The new version will be released in a couple of days and I will also update the manual.
Basically, you just need to send:
@<widget_uid> REQV:1\r\n
This will return the current value / state for the widget (in the same format as with user interaction).
You can retrieve the values of the TI and NI fields on demand.
Best regards,
Kl3m3n