Access to location of label for SimpleDataField

When you implement a SimpleDataField, you get the label for the field almost for free by setting the variable "label" in the initialize method.

But if you want anything more complicated than a text string, then you have to use a "plain" DataField, and therefore also have to draw the label yourself.

This is easy enough for the various square watches but for the fenix3, it becomes rather difficult as the watch is round and you therefore cannot just place the label in the top-left corner of the data field. If you look at the simulator, you'll see that the label is centered, and the top-most data field is made a bit smaller.

I could see a couple of solutions:

The position and justification to use for the label could be made available.
WatchUi.DataField could add a simple method drawLabel(label) that will draw the label and return the bounding box so we know what space is left for the rest of the data field.

travis.vitek over 10 years ago

I'm pretty sure this is the motivation for the getObscurityFlags() method that was added to DataField. I know I've coded this up before. I could find and post the code here, but that wouldn't be useful to people who don't read these forums.

tonny.madsen over 10 years ago

I'm pretty sure this is the motivation for the getObscurityFlags() method that was added to DataField.

I'll have a look. Thanks for the pointer.

Former Member over 10 years ago

I've submitted a feature request for providing information about the default label location to complex fields.

If having the locations would help you with your current efforts, you can find them in the data field definitions in the devices.xml. The location, justification, and font for the labels on each field are read from there for simulating simple fields.

tonny.madsen over 10 years ago

If having the locations would help you with your current efforts, you can find them in the data field definitions in the devices.xml. The location, justification, and font for the labels on each field are read from there for simulating simple fields.

Thanks for the tips!!

flocsy🤠 over 1 year ago in reply to Former Member

Former Member any news about this feature? :) It would be a pity to wait for a decade to pass.

BTW: I also opened this feature request: https://forums.garmin.com/developer/connect-iq/i/bug-reports/feature-request-add-simpledatafield-setlabel This feature might be easier to implement, and certainly it's easier to use

jim_m_58 over 1 year ago in reply to flocsy🤠

Brian left the CIQ group about 2018 if I recall, Why not just use a complex DF, as after 10 years and 100 more CIQ devices, I doubt anything will change.

flocsy🤠 over 1 year ago in reply to jim_m_58

The reason for not using DataField is detailed in the feature-request. Well, we don't have a choice, but it needs a huge boilerplate that takes half the available DF memory on older devices.

jim_m_58 over 1 year ago in reply to flocsy🤠

I doubt many new data fields are being written for the small number if devices with 16k DFs, and the changes you discuss would likely mean changes to CIQ FW on those devices which wont happen after all this time.

Not sure what "boilerplate" you are talking about, but here's a complex DF I actually first wrote of devices with 16k DFs. with two labels and a whole bunch of data to display a breadcrumb trail. No boilerplate, with what's needed calculated based on the data field and screen size. (fairly simple to do)

apps.garmin.com/.../d741d7b4-8b26-401c-a5bd-0ac91891575d

flocsy🤠 over 1 year ago in reply to jim_m_58

That's a graphical DF, it has nothing to do with SimpleDataField. What I and seemingly other developers want is to be able to use SimpleDataField (because it does give lot of features "for free") that we want to use and that is almost enough for our needs, except that we can't change the label. Also the main concern isn't the memory size, but the look of the datafield.

If you want to write your own "MySimpleDataField extends DataField" then you'll need to address at least the following issues:

- which label font to use
- where to position the label (aka justification + y position)
- divider line
- decide if (bigger) numeric font can be used to display the data or only alphanumeric font ("1.0" vs "1.0 km")
- calculate the position of the data text (aka justification + y position)
- calculate the biggest font that fits the value into the dimensions of the field (- label)
- for all the above: take into account 11 possible obscurityFlag values

It will not be less than 500 lines of code and almost 10kb of code after compiled.

jim_m_58 over 1 year ago in reply to flocsy🤠

The data field I point to is about 600 lines and 14.3k when running. With a big chunk of memory used for an array of locations used for the breadcrumbs. And can be used on really any devices up to the most recent

One common way to save memory with only 16k to work with, was to use dc calls and not use layouts, as there's overhead to using layouts.

The things you mention are all things that people found solutions/work arounds to long ago when everything only had 16k DFs. And like I said, there won't be any new FW drops for devices from 2015-2016