simulator - weird problem (with eclipse).

This is expected behavior. When an app is loaded to the device/simulator, a name is generated (simulator just uses the name as is, on the device it is renamed to an unique name) and the ID in the manifest file is linked to that name. This ensures that that the app retains the same name when it is upgraded via Express or GCM on the device.

This is expected behavior. When an app is loaded to the device/simulator, a name is generated (simulator just uses the name as is, on the device it is renamed to an unique name) and the ID in the manifest file is linked to that name. This ensures that that the app retains the same name when it is upgraded via Express or GCM on the device.

But my point is that in the simulator, it doesn't use the real name - it uses the original name, and not what it is currently. It's renaming the file when it shouldn't (the old name) In the simulator, would deleting a file in the settings directory allow the real (current) name to be used in the simulator directories?

In order to prevent the file from being renamed, you'll have to give it a different ID in the manifest.

I think that renaming a project was something missed in the design of the 1.1.2 simulator. This is a development environment. If I rename a project (for what ever reason), the name should be consistent across the development environment.

If my project is now named "ABC123" instead of just "ABC", things like name of the Object Store file for the simulator should be "ABC123.str" after the change. Changing the ID in the manifest file can be done, but would also cause problems if a version of this project is already in the app store with the the old ID.

This is a development environment and things change (like names) by app developers.

Where is the id/name mapping for the simulator stored, so I can delete it when I rename a project? Changing the ID isn't a good solution, IMHO.

It's like deleting the .str files in the simulator data directory when the simulator starts. NO device deletes .str files like this, so why is it done in the simulator? It seems the only .str files deleted are those not written by a .prg, and a case can be make for .str files that are not written, but used for configuration (things like a color scheme).

It's like deleting the .str files in the simulator data directory when the simulator starts. NO device deletes .str files like this, so why is it done in the simulator? It seems the only .str files deleted are those not written by a .prg, and a case can be make for .str files that are not written, but used for configuration (things like a color scheme).

1.1.2 devices will remove .STR files if they do not belong to an app currently loaded on the device, so the simulator is behaving like the devices in this case. Deleting the sys.nfm file should cause the new name to be used instead of the original.

1.1.2 devices will remove .STR files if they do not belong to an app currently loaded on the device, so the simulator is behaving like the devices in this case. Deleting the sys.nfm file should cause the new name to be used instead of the original.

With the STR files, that's not what happens with the sim. The prg file is in the apps directory, and the .str file is removed from the data directory when the sim starts, unless the .prg wrote to that .str file. If the .prg uses it for config data (never writes it), it's deleted.

Just tested that again to make sure

Example. "watch" that uses a .str to define colors (it's only read). Copy .str into data directory (watch.str) and run watch.prg (it's now in the app directory). Stop the simulator, both files are still there. re-start the simulator, watch.prg is still in the apps directory, but watch.str is gone from the data directory.

If watch.prg does a save property, the watch.str remains after a restart of the simulator.

This is on windows.

update: Did a bit more testing, and it could be the .str is only persevered if it is created by the .prg.

Both Kyle and I have tried reproducing this (Kyle on Mac, me on Windows), and haven't been able to. The one case where the STR file gets deleted is when there is an STR without a matching PRG file, regardless of whether the STR was created by an app or created manually. This is by design. Otherwise, the STR files never get cleaned out if there is a matching PRG.

The one thing I'd ask you to check it to make sure your PRG and STR file names (prefixes) match. For example, if one is all caps, and one isn't, or one gets truncated to 8.3 and one doesn't, etc., then what you're seeing could occur. Your "watch" example doesn't appear to fit either of these scenarios, but I want to make sure.

A few other questions:

1. Are you able to reliably reproduce this with any PRG?
2. How are you launching the simulator?
3. How are you executing the PRG?

I've created a ticket to make the check not case sensitive.

Thanks. In the mean time I'm just making sure that the case is an exact match. I deleted the sys.nfm and all the .prg files in the apps dir and everything in the data dir, so it was a clean start, and with matching case, the .str files are being retained properly.