Settings Editor does not show changes made to Properties.xml

The options I get are Edit Application.appBase data and Edit Application.Storage data

Both produce "This app does not have any saved any objects..." with the incorrect grammar as shown :-)

My app uses settings from the start and there is a .SET file in the %temp%/GARMIN/APPS/SETTINGS directory with the correct time stamp, and I've verified that the app is reading it's contents and writing to that file.

I've also looked in the settings.json file in /bin and can see the text that I'm changing in Properties.xml and confirm that when I change it in Properties.xml and rebuld, the contents of settings.json contains the change.

Jeff said:

Do you know where the Settings Editor gets it's idea of what should be displayed ?

Apparently it's not coming from settings.json in /bin

As Jim said, it is that file.

I can verify this for myself by editing the file in another text editor (it can't be deleted while Eclipse is open).

- If I delete all the contents and re-open the settings editor, then no settings are displayed

- If I edit a field title in settings.json, then that edit is reflected in the settings editor.

To me it sounds like the same issue where the settings editor somehow thinks that your project is in the old project location.

Have you looked in the old project location recently? Does the bin/ folder still exist? Does it contain the output of a recent build?

You can try to diagnose this problem on Windows using Process Monitor: https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

I tried this with following filters:

- Path contains "settings.json"

- Process Name is "eclipse.exe"

When I build my app or open the settings editor, Process Monitor shows the full path of the settings.json file that's being read or written by Eclipse when I build/run the app or open the settings editor. In your case, I would expect it to be looking at a file in an unexpected location.

(If you want to trace what the simulator is doing, the process name is "simulator.exe")

Jeff said:

The Settings Editor does not show changes I make in properties.xml

Sorry, I glossed over the fact that you said *properties.xml*. This is expected behavior: see below.

Jeff said:

I'm beginning to think that the Settings.xml file has to be changed for a change in Properties.xml to show up in the Settings Editor.

I'm using an entry in Properties.xml to put a header above some fields in the Settings Editor.

This line is in Properties.xml -  <property id="coursesHeader" type="string">Define Courses</property>

This line is in Settings.xml -  <setting propertyKey="@Properties.coursesHeader" title="@Strings.spaces">
<settingConfig type="alphaNumeric" readonly="true"></settingConfig></setting>

You're seeing that because the value in the property definition is only the *default* value which is applied when the app has no settings (or when the property in question doesn't exist.) Once the property is created and stored in the SET file, further changes to the default value won't be applied to the app settings. Otherwise you would be potentially wiping out settings changes that your users have made.

IOW, the sim/device doesn't try to track whether the user explicitly set a given value or not. It's no different than if you had programmatically changed the value of "coursesHeader" in your app code. Once that value exists, the default value from properties.xml is going to be ignored.

You can use "Reset all app data" in the simulator to clear out settings.

If you really wanted to try to migrate default property values in your app, you could try to set them programmatically in the code, but you'd have the same problem of not knowing whether the value came from the user or a previous default. It would only be useful in the edge case where you've deprecated a previous value, or when the setting is readonly. Either way it would be waste of precious code/memory, as well as a pain point for code maintainability.

Jeff said:

Under what conditions do the Properties / Settings for an app get erased as the result of a change to the Properties / Settings files ?

In my test, adding a field erased all settings.

I don't want that to happen to people who have the public app.

That shouldn't happen. In the past there was a bug where app settings to be erased on every update, but that was fixed a long time ago. You can test this using your beta app in the store.

Is your app close to the memory limit? If you push settings while the app is running, this causes a memory spike. If that spike causes the app to run out of memory, then existing settings will be deleted.

Ahhh.... thank you.

The fact that the sting in Properties was a default was lost on me. 

Thanks for the heads-up about the memory spike when settings are pushed to the running app. I'm beginning to use that feature and have not yet run into a memory issue but I'll check to see how close I am.

All of this came from wanting to put a couple of lines of text in the Settings that would appear before some fields, describing the format to be used for entry. So far I haven't found a way to do that.

If you know of a good approach to that please let me know.

Thanks again.

I tend to keep my setting, properties, and stings for settings in the same xml  Here one with a single property and setting, where the usre can enter the station or I can change it from the app.  The default is no string.

<resources>
    <properties>
    	<property id="station2" type="string"></property>                       
    </properties>

    <strings>      
    	<string id="station">WU Station ID (current)</string>
    </strings>

    <settings>
        <setting propertyKey="@Properties.station2" title="@Strings.station">
            <settingConfig type="alphaNumeric" />
        </setting>          
    </settings>
</resources>

Sure, np!

Jeff said:

All of this came from wanting to put a couple of lines of text in the Settings that would appear before some fields, describing the format to be used for entry. So far I haven't found a way to do that.

Unfortunately there's no good way to do this. One approach that I've seen is that some developers have very long label text which apparently includes newlines (for readability). Unfortunately, depending on the app/platform you use (e.g. Garmin Connect on iOS), newlines will be removed from labels.

There's one very popular app which has a label that should be a couple of paragraphs and a bulleted list, but it ends up being one long line of run-on text.

Another issue is that some Garmin app/platforms will truncate long labels, IIRC (e.g. Garmin Connect on Android). Not sure what the current state is.

All of which is to say that you can't trust the rendering of settings labels in the Eclipse / simulator settings editor, you have to look on the real app. And you can count on Garmin Connect to behave differently on iOS vs. Android, which will both be different from Garmin Express (PC) and the Eclipse settings editor.

The terrible workaround I used for this was to add lots of non-breaking spaces (not newlines) or horizontal box drawing characters to my settings labels, to simulate the appearance of multiple lines. Ofc this doesn't work very well across different apps and screen sizes.

I posted a feature request years ago for better/more consistent settings label rendering (or options to have this kind of stuff built-in to settings, such as a "description" or "help" element), but it looks like it's never gonna happen.

Another pet peeve of mine is that there's no way have conditional settings - e.g. show/hide field X based on the value of enum/boolean field Y.

Thanks once again.

You just saved me the time of hunting for solutions where there are none.

Seems like old fashioned documentation is the answer at this point.

I appreciate your help.

Jeff