@Hub

I am happy you find the improvements useful!

Thanks.

Regards,
Klemen

@SteveV Hi!

You mean you cannot enter IP address due to not having any period ('.') character available?

This is not normal. Can you try changing the keyboard from Android settings and see if the issue persists?

I am "forcing" the number keyboard when user touches the IP field... In most cases, the keyboard also shows other characters. Anyway, I will fix this ASAP - I have a release lined up right now. I will probably take a day or two...

Best regards,
Klemen

@Bernard Yes, you have wrong credentials. This is what's causing the problem. You have changed the settings somehow...

I advise you to clear application data or uninstall and reinstall the application. This will reset the settings to default. Alternatively, you could input the correct settings, but I recommend reinstall... It will be easier for you. Then retry pairing.

Note that you must keep the default settings if you want to connect to GUI-O server!

Best regards,
kl3m3n

@AndrejK Hi!

Please see:

https://forum.gui-o.com/topic/60/assign-a-number-to-ni-through-a-variable/2?_=1736064840303

and

https://forum.gui-o.com/topic/225/how-to-display-a-float-number-via-bluetooth/6?_=1736064823080

Does this help?

Best regards,
Kl3m3n

@gammda Fixed in v1.0.91.

Best regards,
Kl3m3n

@gammda Hi.

I will check this ASAP. Can you please send me the label initialization?

Best regards,
Kl3m3n

@enniom Hi!

#1 - I agree with your suggestion. In the next release, the numbers will be displayed outside the actual chart area, live you've suggested.

#2 - This is strange - in your video I see GUI-O is receiving invalid characters (ABV%).
After you quit the application with the command, you then open GUI-O from "recent apps" and what do you do next? Your video does not show this. Do you connect to the device manually or you use auto-connection feature to re-connect automatically?

Can you try quitting only when all Bluetooth transmissions are complete and Bluetooth is disconnected?

Best regards,
Kl3m3n

@enniom Why are you setting ASR to 0.5, if no device has 0.5 ratio? Which is your development device?

Kl3m3n

@enniom Also try installing this app:
https://play.google.com/store/apps/details?id=com.drhowdydoo.displayinfo&pcampaignid=web_share

You can check the various screen information.

@enniom

Addition to previous response:

Can you tell me, which device you have (the problematic one where the widgets are partially off-screen)? I assume that the dpi value is different than the one used by GUI-O. I think if the exact dpi is used, your widgets would not render off-screen.

Ignore the WBE parameter, since it is actually of no practical use...

I will add the dpi reporting to "developer mode" in the next release.

Regards.

EDITED

@enniom Hi!

I will take a look at this thoroughly tomorrow - today, I am too tired... It was a long day

Just a quick note - dealing with devices with different sizes is a bit tricky. Note that you cannot rely on raw pixel sizes when calculating the positions, due to different screen density of devices.

For example, you can have two devices with the same raw pixel sizes (e.g., 1920x1080), but their densities can differ. This means that e.g., a square with 100x100 pixels will have different physical size on both devices.
So, the calculations need to be based on physical screen size. You need dpi (dots per inch) value to calculate the actual screen size. Android reports the dpi value in "buckets" (120, 160, 240, 320, etc.), which can be different from actual dpi value of the device. This means that calculated physical screen size is not exact (I could use exact values, but some Android devices have problems reporting this exact values, so this is unreliable). I believe this introduces errors in positioning and scaling.

Furthermore, you generally don't need original screen sizes if you use percentages for positioning and sizing on another device. The aspect ratio ensures that widget ratio is preserved. Using the physical screen size ensures widgets are within the visible area.

Best regards,
Kl3m3n

@enniom Hi.

GUI-O already scales based on the "reference / base" aspect ratio. That is why it is advisable to specify the aspect ratio of the development device if one develops for different screen sizes.

Basically, the device independent pixels are used in the calculations, but the ratio of the widgets must be maintained. If GUI-O would not account for this, you would get all widgets on different devices with "corrupted" aspect ratio.

In some cases, the scaled canvas extends beyond current device size, which makes the widgets go off-screen. Possibly due to device reporting inaccurate screen size, I don't know. I will double check my equations.

The scaling equations are (pseudo code):

REF_RATIO = REF_DPW / REF_DPH  (ASR)

// INITIALLY SCALE BASED ON HEIGHT
DPH_E = DPH
DPW_E = DPH * REF_RATIO

// FALLBACK TO SCALE BASED ON WIDTH
if (DPW_E > DPW) {
 DPW_E = DPW
 DPH_E = DPW_E / REF_RATIO
}

// OFFSET
DPW_O = (DPW - DPW_E) / 2
DPH_O = (DPH - DPH_E) / 2

//  WIDGET POSITION
X = ((DPW_E * X_%) / 100) + DPW_O
Y = ((DPH_E * Y_%) / 100) + DPH_O

//  WIDGET SIZE
W = (DPW_E * W_%) / 100
H = (DPH_E * H_%) / 100

Note that almost all widgets are custom made by painting directly on the canvas. This makes the widgets more flexible and modular. If replacing with SVG, this would be very difficult.

Best regards
Kl3m3n

@enniom Hi!

Yes, I see. I will need to implement some additional global scaling of the widgets when repositioning them.

I cannot implement a widget collision detector, since "collisions" are legal in GUI-O. Currently, I see scaling as the only option...

I will let you know.

Regards,
Kl3m3n