Hi Martin,
That didn’t go as well as you indicated!
Here is what happened:
· Changed field “APPLICATION DIRECTORY�? from “C:\TouchGFXProjects�? to “V:\TouchGFX�?
· Created simple project 2 screens one button each that switches to the other screen project was saved on drive V as requested.
· Closed and reopened the designer build another simple project field “APPLICATION DIRECTORY�? points to “C:\TouchGFXProjects�? and a sample project was save to drive “c�? which is a NO!NO! .
Ultimately the project will have to be stored on the company network to a pointer that would look like:
\\Alternate\V\touchgfx <> project\%USER%\
This is a corporate decision to store project file were appropriate security and backup are maintained it’s not up to the designer.
While I was looking into this I got errors due to the use of spaces in file path this is a major hurdle.
Because of the number of path that would have to be changed on the network. And then updating all the references in all the files.
On our network “programfile�? and “program file�? are different valid folders with different function and cannot be combined.
Good luck>
Version 4.13.0 still has this issue (default directory, not tried spaces in directory names). Given a full C drive, TouchGFX has selected installation on the D drive, yet the Application Directory defaults to C:\TouchGFXProjects. This is an unfortunate usability flaw in an attractive UI
I have also tried loading an image file with a space in the file name - the UI reports an error and allows you to load a different image file (e.g. copy and change the name of the one previously selected, t.b.h. I couldn't see a way to undo adding the image), but leaves the file with a space in loaded into the project (which stops the simulator or target running, but Generate Code still works and reports no errors - only a red outline on the Images button). This is another usability glitch - I think the application could benefit from being tested by someone unfamiliar with it.
As a developer I know how easy it is to always test in the same manner - having someone else test your application / module tends to reveal actions that the developer would never consider the user doing. Having an 'idiot user' test an application (particularly one with an attractive UI, as there's less 'common knowledge' of how it works) is very useful
I agree with you. It's something we've not prioritized for a while because there were more pressing matters, but i've raised the issues again internally. Thanks for your feedback!