Best Design Pattern for Multiple Instances in a App

perhaps wrong terminolgoy… but I am going to create an app that has a “main” window “type” this window manages a suite of data related to a specific file on disk (including a UNDO stack). I would like to design it in such a way, that I can create multiple instances of this “main” window and each operates independent of the others, but SHARE common dialogs like LOAD/SAVE, etc.

only thing I would be cautious about is separate undo stacks in each window for a single item like a file on disk

if I do something in one window then is it only undoable in that window ?
or should THAT undo stack be a singleton that is app wide ?

or does each Window manage one file per window, and each file is different

Reminds me of the confusion with undo between tabs of the Xojo IDE.

  • Karen

in the IDE undo is global (or was unless they’ve changed that)
BUT should return you to that tab & state (that was the worst thing)
It often didnt because it didnt have the info to do that for a very long time
it got marginally better at this over time but still had issues returning to the state of the UI when you continuously pressed undo

In regards to this applicatioin, each window will be dealing with a PNG file (think msPaint), but that does beg the question of what if the user opens the same picture in multiple instances

Indeed
In that case maybe “last writer” to disk wins
So each can keep their own undo stack but whoever saves last is whats on disk

but nothing indicated how best to handle this.

Create a master class for the window, and have it contain instances of any other classes it needs?
Therefore making each window class basically a copy of the entire program

not sure exactly what you’re asking here ?
how to handle the undo stack ? How to implement one ?
or something else ?

the basic concepts behind implementing an app the can instatiate multiple instances of its main window and how to compartmentize unique vs “global” properties

Sounds like you’re building a document based application, to which there is already a template in Xcode. It may already handle trying to open multiple instances of the same file, I’ve never tried.

1 Like

Having helped a company build a full fledged image editor with workflow same as that of PS here are my inputs:

  • Build a tab interface where each window is represented as a tab and a user can switch easily between open files or windows.
  • Undo stack should be separate for each window and also give facility to export/save the Undo stack to disk so that in future a user can open the file in question and the software should either automatically load the undo stack for that file or ask user if the user wants to load the undo stack.
  • Allow only one copy of the file to be loaded. So if a user tries to open a file multiple time inform the user that the file is open and offer to switch the user to that file.
  • The approach for Dialogs should be that when a dialog opens it should automatically get attached to the active window.

HTH

1 Like

I thought the old MDI approach was along these lines:

A document related to a file, holds the data in a class.
A window is given a pointer to the object, and is used to both display and amend it.
The object handles the undo-ing.

If the same file is opened in another window, that window is given the pointer to the existing object for that file, not a new object.
Both windows can display whatever needs to be displayed - perhaps in different zoom settings/ scroll positions / ways
Changes made in one window will cause the display in the other window to update - either immediately by asking it to update, or when invalidated/refreshed in the usual way.
The object knows if it needs saving, not the windows individually.

1 Like