Last active yesterday
If it is true localisation, I would expect all visible labels to be changeable to the new language - eg in Resources, Product, Short desc, Contact name etc, should be changeable to words that are similarly meaningful in the new language.
Is this not what you intend?
I agree that I see no problem with unused Contacts or any other component.
What I do see is an opportunity to use Resources (or indeed Contacts) in a different way by having the ability to change the labels.
I've had a look at the comments on BdJ.
I particularly noticed the one about hiding business info.
I don't know if there might be some value in hiding components on the program - I very much doubt there being many users who use them all but the business side (contacts/resources & etc) does speak to a particular design philosophy and purpose which was a big thing when Do-Org started. But times have moved on and most of this use has now moved online - into the cloud or corporate servers - even for SMEs.
Personally I see little need for hiding. An unused component doesn't really get in the way.
But I do see a lot of potentially usable functionality that I don't use because the database items are hard-coded. This is the sort of thing I was talking about when I was looking at the possibility of repurposing with the language options when they come.
I think it is exactly the same as code folding, except in a text document rather than code in a text editor.
Allows working in sections in a single large document which can be much easier than working through lots of sub documents. If necessary, we could add a note in a text box to indicate exactly what had been folded away.
Just to say I would really like this as a feature. It's not found in most document or writing programs (with the exception of Writemonkey) but is quite common in text editors.
@Chris Yes, more tools will be made available, such as a raw database editor to get into the finer details of the SQL data within your database. ;)
I do like the idea of a database editor. Partly because it allows an alternative way of accessing the data.
But also because it might offer the potential to edit labels etc. I'd use it a lot in the resources and contacts sections which have limited utility for me as is. I'd happily pay extra (up to a point!) for this functionality. I suspect it would be a function that some people would use a lot and most others not at all.
Very interested in Android client. Too support the use of the desktop client rather than as a standalone.
I would expect a limited set of features; just enough to keep me working when out and about. I would be most interested in working on Journal & Documents. I suppose Email, Calendar & Tasks will also be needed. I would be concerned that it did not become too big or complex because mobile screens are smaller (ie too complex is hard to work with) and because it could potentially overload your development time.
Location of the shared database would also be an issue. Options appear to be Dropbox, Google Drive etc or your own cloud (requiring a subscription).
I assume that this will also permit repurposing eg of the Resources files. If you don't need a product you could rename the categories to make them something else?
Brilliant! Really glad you've managed to pin it down.
I can confirm that the problem exists. Doesn't seem to be a problem if saved manually, and I'm not sure it always is on autosave (my test docs seemed to be still there). Maybe it is an issue only with open docs or with docs that are open in their own window.
Lost some stuff on the last crash which had been there for over 12 hours.
I've not experienced any autosave problems with other programs.
The 'crashes' are of the system freezing and having to be restarted.