Track properties needs to be normal window

The track properties dialog disappears when I switch to another application (and then comes back when I switch back to BaseCamp). This makes it very difficult to view my track points while working in some other application, such as a photo organizer, where I want to synchronize my photos to times of the track points.
  • Former Member
    0 Former Member over 14 years ago
    I'm with you.

    I'm not an OS X developer, but it appears as though this may be a defined behavior for child-windows on the Mac. All of the apps I have do this.:(

    I much prefer the Mac-BC UI over the Win-BC UI implementation but one of the benefits of having the "properties" in a Window pain of the main app like Win-BC is that you don't have child-window focus issues.

    I think someone already asked for this on another child-window topic - have the option of docking [Info] windows when the user desires.
  • I agree it would be nice if the window did not disappear when another application or finder was active but it probable has something to do with the window being an active drag window. I like being able to just drag a waypoint into a route window and have it inserted into the route. If the window stayed up and someone tried to drag an email to the window, it would probable require much more coding to make the window ignore everything except waypoints. I am sure it could be done, I just don't have any ideal how many hours or minutes of coding it would require. Form the way update are going I bet the question is not if but when. In the mean time I take a screen shot if I need the info in another app.
  • Former Member
    0 Former Member over 14 years ago
    It is indeed standard behavior in the OS for that kind of child window to hide when the app isn't the in-focus or active app. We'll look into that behavior and the issues that would result from changing it.

    Currently, a workaround for having the contents of that window still visible in another app is to take a screenshot of that specific window and look at that instead.

    You'd take the screenshot by hitting cmd + shift + 4, then space and clicking on the window you want. This saves a screenshot to your desktop (to default).
  • You learn something every day, one of the most used features on my mac is shift + Command + 4, you get a cursor with cross hairs and I draw a box around what I want. I never knew about hitting the spacebar, getting a camera cursor and on clicking the window you want. Now I want Lion to capture the entire window with a scroll bar when viewed in preview.
  • I mostly deal with tracks and the screen shot is a good easy solution. I noticed MORRIEGASSER was takling about tracks which are a different issue because a screen shot will only capture what is viewing on the screen. If the complication cause by changing the actions of a child window contrary to apple guide lines is too involved, how about a print button were users could print to a pdf for viewing. The code is there for the directions windows and some people a big into printing everything.

    I don't know how hard it is to transform windows but another solution would be a transform the window from a child to regular window when BC lost focus and back when it gains focus. Personally I think the print button would easy to add and be a better solution for everyone. Another advantage is users could search the pdf of coordinates, time, etc.
  • It is indeed standard behavior in the OS for that kind of child window to hide when the app isn't the in-focus or active app. We'll look into that behavior and the issues that would result from changing it.

    While standard behavior for "child" windows, it is not required for all windows. Photoshop and many other applications for example can have multiple document windows open at once that don't disappear. You could easily make the track window a top level window in the application, at the cost of some additional management to get it to behave (mostly) as if it were a child in other ways. Another example is BBEdit, whose find and search results windows don't disappear when you switch to another application.
  • While standard behavior for "child" windows, it is not required for all windows. Photoshop and many other applications for example can have multiple document windows open at once that don't disappear. You could easily make the track window a top level window in the application, at the cost of some additional management to get it to behave (mostly) as if it were a child in other ways.

    I am sure it could but main stream developers have to follow the OS rules these days, there are just too many variables. You must not have read the post above yours.
  • Former Member
    0 Former Member over 14 years ago
    While standard behavior for "child" windows, it is not required for all windows. Photoshop and many other applications for example can have multiple document windows open at once that don't disappear. You could easily make the track window a top level window in the application, at the cost of some additional management to get it to behave (mostly) as if it were a child in other ways. Another example is BBEdit, whose find and search results windows don't disappear when you switch to another application.


    I run Photoshop Elements at home and that app's the king of panels when run in its seamless mode; they all disappear besides the drawing window, which reduces clutter, I guess. If the panels are all running inside one main window, I think the behavior's closer to what you described.

    Rambling, I guess, but I just wanted to say that the "standard" behavior for this specific case isn't as important to us as whether or not it's desired/expected behavior for the user. People generally aren't aware of whether or not something's a "panel" or child window; they just know if something's cluttering their screen or invisible when they don't want it to be. We're looking into it :).