I'm changing the body of a MailItem object associated with an Inspector, and I would like to restore the original state. Currently I'm saving the original content (i.e., email body, subject, etc) and setting it back again, but whenever a user closes the Inspector he is presented with a dialog asking if he wants to save changes. Does anyone know if there's a way to restore the original MailItemwithout having to present the user with a dialog asking if he wants to save it?
Don't do that. If you need to display data different from what is stored in Outlook, create a form region, task pane, or a custom message form. Resetting/restoring is a hack that will break at the worst possible moment.
Related
I am not very experienced with Qt and I have trouble doing what I want.
In my application, I search for archive files with password on a disk (that part works) and I want to ask the user for the password each time I find one new encrypted archive.
If I find multiple files while user hasn't given any password, I want the dialog for the first password to stay visible until that password is given and then the dialog for the next password can show and so on.
I use some sort of queue to remember which archives need a password, and I am trying to show and hide an unique dialog (actually a Popup) with the info of each archive and get the password from a TextField inside. In the meantime my application is doing other stuff in the c++ code like searching for archives and extracting them when a given password is OK.
My problem is that it is not really working. The dialog shows the first time, I get the first password but then the dialog doesn't show for the next password. Sometimes I can see the dialog a second time, for a few milliseconds, before it disappears without user interaction. My application is blocked because it cannot go on without the unasked passwords.
I get that I am doing something wrong but I don't get what exactly.
Can anyone help ?
I don't know if I was very clear, English is (obviously) not my mother tongue.
I found my mistake.
I did a component based on a Popup.
Inside the onClicked function of the Check or Skip buttons I was doing two things: send accepted() or refused() to trigger custom actions and then close the dialog.
I was doing that in that order, so the accepted or refused action, which among others things triggered the visibility for the "next" password dialog, occurred before the close event, which was setting the dialog visibility to false.
I switched the order and it's way better.
I feel a little silly now but at least I found it.
In my app, i let the user create a record on clientside and fiddle with it prior to saving. The record is of a pretty complex model with a lot of realtionships. To edit the record, a modal dialog opens and displays a form.
Example scenario:
You've created a new record on client side. It's in the blank state.
Then you proceed to edit the record. You make changes to the form in the modal dialog and press OK. The record now is in state A.
Then you proceed to edit the record again, turning the record to state B. But this time you mess the form up and decide to Cancel.
When you hit Cancel, the record should revert to state A.
The problem is that this is an unsaved record and thus record.rollback() can not be used.
All i could think of is making a copy of a record and feeding it to the form. But most of the form's fields are bound to related records, thus, you'd have to clone the record's related records recursively. This is a huge hack that i don't want to go for.
Any simpler suggestions?
The approach I have used is based on the buffered proxy pattern within my controllers.
This way your controller can just throw away the buffer on cancel or apply the buffer to models and orchestrate model saves when the user OKs the changes.
Here is an ember package you can use to get started:
https://www.npmjs.com/package/ember-buffered-proxy
My first question was: should I use dom, sax, or sqlite to save the data the user is inputting into my application. The answer I am going with is to use DOM.
My second question is: How should I load the contents of the file into the application when the user decides to open the file? Should it go through the whole file and distribute all the data to the correct spots in the GUI once the user clicks "open" on the file? Or should it only open the stuff up as the user clicks on certain areas?
My third question is: How does qt handle knowing when things have changed? How would i know when the user has changed something and ask them to save the file?
If you do not understand, please let me know and I will try to explain again.
Example:
I am not only reading gui locations.
But the contents of those. For
instance. The user is able to create
tabs that contain edit text boxes. And
those tabs are associated with items
that are in a list. When the user
clicks on an item in the list the user
will be presented with a whole set of
new tabs. And each tab has some
editing forms. The file will need to
contain what is in the list, what tabs
the user has created under each item
in that list and the contents of each
tab associated with the tab of each
item in the list.
Sorry that I posted another question that is similar to my last, but the other question was answered and now I need a new post.
Question 2: This very much depends on how much data you're dealing with. It will be much easier to load everything in one step. If you are expecting complex documents, it might be better to do it incrementally, but I would strongly recommend starting with the simpler approach.
Question 3: Qt does not handle this, except in as far as widgets will fire signals when they are modified. You need to do it, using a model of some sort. You could just use the DOM document directly as the model, although it may help maintainability to abstract the save format. Each change the user makes would cause a change in the model. You will need to detect when e.g. the user edits some text, update your model appropriately and keep track of whether it has changed since the last save.
What do you want to achieve with your solution? If you want to simply set Configuration why not using a simple Ini file (QSettings Class).
I don't know your application, but you should be able to recognise changes (lets say, if the user changed a QLineEdit or hit a radioButton).
There would be also a "sync" method for QSettings, which "rereads" the file you are working with. Qt won't recognise changes itself, you have to do that on your own.
I have the following situation: there is a table in the DB that is queried when the form loads and the retrieved data is filled into a DataGridView via the DataTable underneath. After the data is loaded the user is free to modify the data (add / delete rows, modify entries).
The form has 2 buttons: Apply and Refresh. The first one sends the changes to the database, the second one re-reads the data from the DB and erases any changes that have been made by the user.
My question is: is this the best way to keep a DataGridView synchronized with the DB (from a users point of view)?
For now these are the downsides:
the user must keep track of what he is doing and must press the button every while
the modifications are lost if the form is closed / app crash / ...
I tried sending the changes to the DB on CellEndEdit event but then the user also needs some Undo/Redo functionality and that is ... well ... a different story.
So, any suggestions?
I would say that the way you are currently doing it is fine. If you start attempting to update the database while the user is still making edits you can run in to issues updating or modfiying things that the user may ultimately decide they did not want to change. Additionally this has the chance to greatly increase the number of database calls.
Forcing the user to click apply helps ensure that only the changes the user actually wants are sent to the database.
As for losing the changes if the app crashes before applying them, I would be more concernced with why the app is crashing.
The only important thing to remember is that you should refetch the data before saving it and the refetched data should still match the data you originally displayed to the user. If it doesn't, someone else made a change your user will be unknowingly overwriting. Your users probably will not like that.
How you handle this is dependent on what your client needs in their database.
I find this situation comes up from time to time, and I never seem to have a really robust generic solution to it.
I have a control - in this example an EDIT control on a dialog. I want to take certain actions in response to the user - and only the user - modifying the contents of the edit control.
The edit control can be set programmatically - e.g. when the dialog is being setup, there may be an initial value placed into the edit field. Or when the user selects an item from a listview, that selection's text may well be what's placed into the edit field.
But when the user modifies the contents of the edit field, I need to know that, and respond (in this scenario, I want to clear the selection from the corresponding listview).
I am currently looking at what control has focus, and only considering EN_CHANGE's to be "from the user" if the edit control has focus.
This works beautifully under Windows 7. This fails under XP (I haven't tested Vista yet).
In XP, if the edit field has the focus, but the user clicks on the list view, and the list view tells the edit control to set its contents, then I get a notification from the edit control which claims to still have focus (::GetFocus() == HWND of edit control). But this incorrect state doesn't occur in Win7.
This is a layered interface, so I cannot modify the list-view notification handler. It gets a selection change, and updates the edit field without my involvement or ability to really intervene other than to get notifications from both of them.
Any thoughts on how to generically, permanently solve the "Is this control notification really from the user" conundrum?
You can always track LVM_ITEMCHANGING, LVM_ITEMCHANGED, and EN_MSGFILTER messages. If the edit box is modified between LVM_ITEMCHANGING and LVM_ITEMCHANGED without an EN_MSGFILTER in between then you can probably assume the user did not modify the item. Or just check to see if there are any items selected when EN_CHANGE fires and if not or the text doesn't match the selected item, assume it is a user edit.
Or use ES_MULTILINE (from EN_CHANGE documentation):
The EN_CHANGE notification is not sent
when the ES_MULTILINE style is used
and the text is sent through
WM_SETTEXT.
I'd suggest using the right message. EN_CHANGE is too generic, you want to know if the user typed or pasted text. So why not subclass the control and watch for WM_KEYPRESS messages?
Alternatively, you can set a flag in your other code that sets the edit control content. You might be able to assume that anything that makes your wndproc re-entrant represents a programmatic change.
You aren't looking for something actually secure, are you? If you just want to exclude set content calls that's fairly straightforward. If you want to differentiate between user action and programmatic simulation of user keypresses, that's a much harder problem.