I am facing an architecture question and I am wondering if anyone know if my idea is feasible or has a better architecture idea.
My situation is that I have CoreData data model for tracking some financial data, imagine it is bank accounts (it's not so don't worry about the security thing). Data for the core data objects is mainly user input.
I know well how to make user input screens (implemented as sheets on top of the main window) and how to implement undo for these input sheets. For simple sheets like edit account i simply copy data from the relevant core data object to the sheet's controller and write back on OK-Close. The write back to the CoreData object is wrapped in an undo grouping which gives me a single undoable action to restore the state to before the edit. This works fine.
Now I am contemplating a more complex edit control where the transactions on the account would be shown in an editable grid (like excel) and it would be possible to edit, add or remove actions. For this control it seem difficult to copy all data to a new data structure. Instead I was thinking of using the core data store as the data source directly, meaning core data objects would change, be created and deleted as the user edit rows in the control. Within this control i then know how to get step by step undo.
The issue comes upon end of the edit session if the user then clicks cancel. I figure to handle this instance I could wrap all actions in the control into one undo group and undo that.
The issue is that after this the canceled actions are then available as a redo on the redo stack. This is cleared as soon as the user does another undoable action but I would like to ensure that this redo action is never recorded at all.
A work around I have thought about is to do some (no-op) action that is undoable after the cancel to clear the redo stack, but then this no-op shows up in the undo stack instead which is also undesirable.
Basically what I'd like to do is to do some form of core data rollback to the state before the complex edit sheet is activated without this rollback being re-doable. The edit sheet is modal and it can be guaranteed that no other changes will happen in the core data model while the edit sheet is active.
Also worth knowing may be that the core data context is not guaranteed to be saved before the edit sheet is activated so simply throwing away the context and reloading from persistent store is not an option. (And would also lose previous undo history as well which I do not want)
The simple question is then, how do I clear the redo stack of the core data NSUndoManager? More generally does anyone know if this is the right solution to my problem or where should I look for a better design solution?
Related
I have little experience in developing GUI for desktop applications, but I want to develop a typical GUI for creating/editing entities (e.g. Customer, Suppliers, etc.) which would be similar for many cases and would be comfortable for the users.
[* Please don't close the question. I put much effort in preparing the question and I really need help. *]
After analyzing our tasks I designed the following possible options:
1) In simple cases it is possible to solve the task by using an ordinary grid:
I.e. the workflow is: On pressing the Add button, a new row is added to the grid. On pressing Delete the user is asked for confirmation if he/she really wants to delete the focused entity instance. On pressing Save all previously made changes are saved. On pressing Close the form is closed (user is asked if he/she wants to save changes before closing).
Cons: I think such a GUI will only work for very simple cases. Editing something complex in a grid is not comfortable neither for a user nor for a developer (implementing complex editing in a grid will not be trivial I think).
2) For more complex entities the following option is possible:
The grid is used here only in the read only mode. On pressing Add a modal form for filling information about a new entity is shown. On pressing OK in that form the data is validated and if everything is ok the object is added to the grid datasource. On double clicking on a grid row the same form for editing the chosen entity instance is shown.
Cons: For every entity we will have to create 2 forms.
3) Another possible option:
The grid is also in the read only mode. When focusing a row in the grid, the fields above the grid are filled and a user can edit them. On pressing Add a new entity instance (object) is created and added to the grid's datasource, then the new row is focused, fields above the grid are cleared (binding helps here), the cursor is placed to the first field and the user can start typing.
I don't see any cons here except that maybe you will not have enough place for the grid and the fields on the same form. I like this option though I don't remember that I saw it anywhere.
I tried to ask the users of my program to help me decide which GUI is better for them, but the typical answers are "I think both options are ok" or "I don't know, you decide which one is better".
Now I would like to ask people with experience in GUI design the following questions:
1) Which option do you use usually? Maybe another one (not shown above)?
2) Would be nice if you also said a couple of words about your implementation (dataset/custom business objects/binding, etc.)
3) Which cons did you notice in my options?
4) Any advice on what I can read on the subject?
Thank you for help!
Junior1993, This is a great question, and there are many online resources that will spell out the trade-offs of each of these interaction design patterns, when to use them, and when they are most effective. You did not provide project-specific details, so it's impossible to answer those questions.
The "Work With" pattern is the foundation of your write-up, and you were asking about the pros and cons of different variations. Here is some reading on "Work With": http://quince.infragistics.com/html/PatternView.aspx?name=Work+With
All of the patterns you described are well-documented and can be modified to fit different purposes.
Your #2 pattern is "Edit-In-Place". It can also be found on the Quince site.
Your #3 pattern is "Two-panel selector".
This one takes many forms, but it helps to preserve context while editing.
The one you did not mention was "New-Item Row". You might want to look at that one, too, and select the pattern or combination of patterns that best fits your users' goals and the content they are creating/editing.
There are other pattern websites out there, and most build on the work of Jennifer Tidwell, author of "Designing Interfaces", an interaction design classic.
Best of luck to you!
In a GUI application (desktop or web), there could be multiple editable text boxes in one page/window/whatever. Do people maintain one undo buffer for each text box, or just a global buffer for the entire page/window/whatever? What's the usual practice?
GMail example
There seems to be one global buffer for GMail (or maybe for browsers?). I can't undo email body edits and email subject edits separately.
I think this comes down to what users would expect from the type of app. If you think of MS Word, the undo buffer is per document. On the other hand, in a business app, if the user visits multiple 'pages' to accomplish a given task, then it could make sense to keep a global undo buffer that includes their navigation history.
The Monitored Undo Framework is a .net library that allows you to set up these 'scopes' of undo at whatever level you see fit.
I have in my model an object, that when modified requires a large number of other objects to recompute values based on those changes.
The way this is currently set up, is that this one object can only be modified in one place. This is a sheet with a Cancel and an OK button. Once the user commits the change, the sheet shows a progress bar and starts processing the objects affected by the change. The presentation and dismissal of the sheet are wrapped in a NSUndoManager group. The user may undo all changes in one pass after dismissing the sheet.
What bothers me is that I keep thinking that all this should happen at the business level. Rather than at the controller level. I.e. I should be able to modify my business object any place in the UI and code and have it trigger the necessary computations.
So I would set up KVO to watch my object and trigger the long running operation when needed. Once I go down that path, I start hitting walls.
How do I coalesce changes? My object has several attributes. I don't want to start a computation when the first attribute is changed and the second is likely to change next. Basically I need an edit sheet and some control point to commit all changes at once.
How do I add a UI to this long running operation? I could have an NSOperationQueue attached to the NSManagedObjectContext and have my window controller observe that. When the queue is not empty, I would pop up a sheet with a progress bar monitoring the current operation.
How can I implement Undo/Redo support? If I delay recomputation to an operation running after the fact, I cannot imagine how to undo the initial change and the propagated once at the same time. I can only imagine undoing the original change and having that trigger another reevaluation of all other object.
In short:
What is the best practice for such dependancies?
Is the propagation a job for the model layer or the control layer?
I believe I came up with a solution:
the center-piece model object watches itself for changes
on change, it creates or amends a ToDo object
the controller watches for new ToDo objects
the controller dequeues the ToDo, presents a progress-bar and performs the operation
I would like to create a custom tool or button in Arcmap that programmatically fills in a number of attributes of selected features for a layer.
To keep things simple, lets say my Arcmap project only has one SDE layer, and I'd like to populate the Date_Created field.
The SDE layer being edited is versioned.
I have some code that partially works, but after the selected records are updated, the layer can no longer draw stating it's in a closed State.
link text
I appreciate any suggestions on how to accomplish this.
Thanks,
Frank
I think that this behavior may be related to management of the edit operations in your script.
Any edit operations that you start must either be stopped (completed) or aborted. If no features have been edited, the edit operation needs to be aborted.
It's a longshot that anyone can help with this, but here goes. I inherited a VB6 app with a Janus GridEX control. It iterates through records, and is editable. Problem is, if I edit a cell and hit the button to go to the next record, the change is applied to the next record, not the one I was editing. It's like, I need it to finish up the edit before going to the next record. I've had this sort of problem before in VC++, and sometimes you have to "KillFocus" on the control you're on or something. I just don't know what to do here. I tried sending a carriage return, since if you return out of the edit cell, it works, but sending a carriage return manually doesn't work. What's the secret?
Is your grid bound or unbound?
It's hard to tell from your description, but I imagine that if your are having this problem then it's probably bound.
As the other answer asked, is the button the RecordNavigator that is built into the control or is it a separate button? The reason I bring this up again, is that I have seen issues in the VB6 applications I support where a toolbar will often intercept and interfere with how the JanusGrid should work.
To get around this limitation, I have added the following code in the click handler of any toolbars where there is also a JanusGrid control on the form.
If jsgxYourGridName.EditMode = jgexEditModeOn Then jsgxYourGridName.Update
This way any changes are immediately applied to the current row.
If this does not help, then I have also seen problems where the recordset that is bound to the grid gets out of sync with the internal recordset in the grid. You can check this by comparing the bookmark of the grid to the bookmark of the recordset.
Ie. mrsYourRecordset.Bookmark = jsgxYourGrid.ADORecordset.Bookmark
At one point I may have also used something like this.
jsgxYourGrid.ADORecordset.Bookmark = jsgxYourGrid.RowBookmark(jsgxYourGrid.RowIndex(jsgxYourGrid.Row))
Finally you can try setting a breakpoint in the BeforeUpdate, RowColChange and/or AfterColUpdate events of the grid, to see what record the grid is really on when clicking on the button.
It depends whether the button is internal to Janus GridEX or not. If it internal then just about the only thing you can do is look at the events the control exposes to see if there a sequence that can let you know that this problem occurs. Then you can try to take corrective action by restoring the row you moved to and put the edit in the row you left.
If the button is external to Janus then you can use the debug mode to trace sequence of statement that control the transfer of focus to the next row. It could be something out of order or a side effect of the particular sequence of commands. I have run into both with different controls.
Remember that you can edit while in debug mode so you can try different approaches and test until you find one that works.