Start a new topic

REQ: More consistent dialog boxes behaviour

3 small points. I am unsure whether they are Mac-specific:

  • The S/R always remains in the foreground, on the whole OS. Sometimes this might be a advantage, but in most cases it isn't. It should only be in the foreground while CT is the active window (and it should not be sent to the background, see next point).
  • Opposite, but similar case with many "Save as" dialog boxes. One false movement or click after triggering it (maybe an urgent mail that needs to be answered immediately or a Skype call) and the dialog box is behind the main window, only getting visible after minimizing the main window (or pressing F6, showing all windows as thumbnails, some Mac magic). Shouldn't these bxes always remain in the foreground while CT is the active window or gets the focus again (urging me to select a folder/file name or to cancel).
  • Once more this (similar to here, the 1st point from there has already been resolved): CT warns that a file is going to be replaced, but indeed it doesn't, even when ignorign the warning. Example: After working on text_project.sdlppx, I want to produce a HTML file. In the file dialogue I do not choose another than the standard name in the same folder as the sdlppx file, and CT warns me that the file will be overwritten. If I ignore this warning (clicking explicitly on "Replace"), CT does not replace the sdlppx file, but creates a file named text_project.sdlppx.html, while the original file remains untouched. A solution here could also be the set HTML_ as default prefix for any HTML file (as for bilingual files).


I can confirm that the second behaviour also occurs in Linux, is very annoying and should definitely not do this (no other program does this).

Not sure about the others, as I don't understand them.

 

Expect some improvements to the dialogs behavior soon, except for the sdlppx file replacement which CT protects even though the native (system) File Chooser warns about the possible replacement.

Yes, I suspected this "replace" issue to be OS-specific. Maybe a prefix "HTML_" could resolve really this quite easily. This would have just another advantage: You never ever confuse these files any more. E.g. when working with bilingual tables from memoQ you can easily confuse them – same icon, eventually no extension displayed, depending on the OS settings (very nice with PMs telling you that they had to copy the whole text ...).

 

Login to post a comment