Funny thing. Whenever I work with multiple windows, whether the windows focus on the same file or different files, Tinderbox invariably starts exhibiting strange behavior and soon crashes. Since starting to work with Tinderbox a few days ago, I’ve accumulated 13 crash logs. Hard to be sure, but I don’t think I’ve seen a crash when I’ve only had a single window open. The instability is so extreme that it would be hard to miss.
I’m using version 7.0.3, running on El Capitan 10.11.6. Has anyone had good luck using multiple windows?
Over the years I’ve sent lots of crash logs into Eastgate, many of them involving multi-window presentations. But even though I usually work with multi-window layouts, I’ve had very few crashes in recent months.
Actually, as I look back through the logs, I see that my most-recent crash was in late March, and that was an anomalous situation. (I had put the machine to sleep while it was connected to a high-rez external monitor, and then woke it back up when it was no longer connected. The shift in display confused and crashed several programs, one of which was TB.)
I see that my most recent bona fide crash other than that was in early March, which was about 20 “Backstage”-beta releases ago in the program’s development, and which did indeed involve a real multi-window issue.
My experience is that Eastgate is very good in sleuthing out the crash causes, from the crash logs, and correcting them. So I would encourage you to ship yours in, as you’re doing. I know how crazy-making this is when it happens, even though it doesn’t (in my experience) lead to data loss or corruption. But after reporting mine, I’ve had no window-related issues in 3+ months of daily multi-window use. Good luck!
I can’t be certain this accounts for all my crashes but it seems the problem was fixed in 7.1.0. The release notes labels it as “The orange window bug”. The bug specifically applies to the situation of working with multiple windows.
The crashes would usually happen when I encountered the orange window bug and tried to close Tinderbox without savings. The subsequent revert action crashed.
Since upgrading to 7.1.0 I’ve not had the problem.
Do you use multiple windows for a single document? I’d like to be able to look at two notes from a document side-by-side, but selecting a note in one window also selects it in the other. It’s as if Tinderbox has a global SelectedNote attribute.
The “tear out” window (view->text window) is helpful for seeing multiple notes, but doesn’t show key attributes or let you link to selected text. Quick links work there though which is pretty cool.
I also noticed that the note selection in one window is duplicated in other windows opened on the same Tinderbox file. I just assumed it was a bug or other limitation, as it gets in the way of satisfying the purpose of multiple windows for me - working with different parts of the document at the same time.
FWIW when TBX 6 first introduced the current window w/ note pane set-up, I was put off by the fact that the note pane showed the same note text in all windows. I quickly realized though that in my case (and obviously your situation may be very different) I wanted to see multiple views (outline, chart, map) and multiple note texts and their key attributes, but that I didn’t care whether the two were linked.
Once that clicked, I settled into a pretty stable practice. I always work with a single window and multiple tabs. These tabs are for the various views I need (the file I have open right now has five stable tabs). Some of these tabs show the note pane, but in several I’ve shrunk it down to nothing so that I only see my map (for example).
But at the same time I’m using the text window hot key (⌥⌘x) like crazy to put multiple notes and their key attributes side by side. These text windows are “lighter” and easier to manage than a full view+note pane window would be and they are also persistent across opening and closing the file, which is pretty cool.
All of which is to say that things didn’t work how I initially expected but with some experimenting, I found a set-up that I think is probably better than what I initially wanted. It took some playing around to find it though…
As I’ve registered here over the years, the TB6 shift to a single-window model was, for me, initially a real step backward in functionality. My working practice involved having a number of small windows open at the same time, for comparison and glancing back-and-forth, much as you can do with the “Quick Reference” feature in Scrivener.
Over the years I’ve come to an approach pretty much like what is described here. For a while I worked with multiple windows. I was put off from that because they were unstable, and the window layout would disappear sometimes when the file was closed (requiring that you recreate it, or retrieve the layout specs from XML.) I believe that the disappearing-window bug is now understood and eliminated. But during the months when it existed I began using an approach like what is laid out here: single window, multiple tabs, very numerous text windows. It allows you to work with the current design concept rather than against it.
Dear all, as a complete newbie to tbx I jsut stumbled upon this issue. I have a container of notes imported from other programs and a container of notes with reference. I would like to copy my notes to the references by having two parts of the outlines open in two windows. I did this by creating a new window and in there new tabs by right clicking on the corresponding sections in the outline. But unfortunately the text-pane always changes to the last used one in all windows simultaniously, so working with two sights in parallel simply dowsn’t work.
Is there a way to achieve working on two sections of a document in parallel? I am more than willed to adapt my strategy, but in the moment I have the impression that with TBX I found the piece of software which works 100% opposite to every intuitive expectation from my usability point of view. Pretty frustrating
The logic controlling tab & window focus isn’t documented and I’ve been unable to define via experimentation. I can see cases where one might want different views to select the same item - whether in tabs of the same window or different windows. However, more usually I want as you do to have different selections per tab that are only changed by the user and not by focusing on a different tab/window.
The best I can suggest is to hoist the container of interest in each window. It seems that if an item selected in window A view is not present in window B’s view, changing A’s selection may not change the selection in B.
Note that the new frameworks used to v6+ mean that drag/drop of notes between windows (or dragging links between windows) is no longer possible. To transfer notes use copy/paste then delete the source note.
Hi Mark, thanks for your prompt response. I am sorry to hear that the deterministic way of achieving what we want to do is missing. But the advantages dominate and are hopefully worth the steep learning curve and the adaption of workflow. I copied now everything step by step from the originating program because doing that between two containers was too painful. When in future my workflow is more tinderbox centered and less mixed those topics might become neglectable.
When working in two sections of the document in parallel, consider working with two (or more) separate tabs, each focused on one section of the document. That will let you move smoothly, for example, between CHAPTER SIX and your BIBLIOGRAPHY within the same window.
Having two outlines in two tabs it works like a charm, the text panes do not change. If I create “new window” by rightclicking on the tab the text-pane changes it behaviour. From that moment on the text-panes are synchronized and change in window 2 to the textpane of the note of window 1 as soon as I refocus window 2 again.
I can accept that it is that way, but I would like to understand: Is this simply a sideeffect or some deeper mechanism which I for sure didn’t get until now? Looking forward to learn something here.