I have an NSDocument-based app where a window for the document may have child windows that need to be queried for changes before the document can close. So I tried to intercept the closing of the document window to do this, but I can't find a reliable way.
I tried to use -[Document canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:] for this, but apparenty this is only called when the document has changes (signalled by -updateChangeCount). If there are no changes, this never gets called.
My other attempt to use the view controller's viewWillDisappear to update the document failed too, as this is too late to register any changes with the document, so they do not get saved (canCloseDocumentWithDelegate:... has already been called at this point.)
What would be the best way to solve this?
Well, I'd say that if the child windows contains changes that have to asked for before the document is closed, the document has changes. And this should be reflected in the (main) document window. However, …
Likely -shouldCloseWindow: should be called, if the document does not contain changes and therefore the document system does not ask for saving itself.
Related
I have a form for viewing data in a table, which can open a pop up form to edit the data.
When data is edited in the pop up form, Access throws a write conflict error upon closing that form and returning to the original.
The strange behavior I'm experiencing is that when I make a change to the popup's class module in VBA, even if I immediately undo the change and save, the error will be resolved exactly once.
To be clear:
I make a change to the popup's class module in VBA (even a change I immediately undo and re-save)
I can open the pop up from my original form, edit records, then close the pop up. No error is thrown on closing the pop up.
I then open the pop up and edit records a second time. Then upon closing the pop up a write conflict error is displayed. This continues each subsequent time.
I now make a change to the popup's class module (again, even a trivial one), the error is resolved for one edit again, and the process repeats.
Does anybody know why this behavior could be occurring? Any help would be much appreciated.
Well the issue centers on if two users, or in this case two bits of code try to edit a record that is already dirty.
If the main form causes the record to become dirty (changed, but not saved), if then you run ANY other code that ALSO changes that data, then you get the conflict.
The simple solution then is to ALWAYS ensure that the the current forms record is safely tucked away and saved before you run + call code that might change that dirty record. And that includes that popup form + class.
So in your code that launches the form/class code? Do this RIGHT BEFORE you launch that 2nd form:
If me.Dirty = True then me.dirty = False
So, the above will safe write out the dirty record, and now you are free to launch/run any other code that might change that record. And because you run the above? Well, the record is not dirty anymore, and thus you should not see nor receive a write conflict error.
So adding a check to save if dirty before you launch/run that additional code/form will resolve this issue. In fact, as a habit, for just about "any" launching of additional UI forms, it a good idea to safe tuck away and save the current forms record when launching additional UI bits and parts.
We are trying to save some additional information with a document using the QuerySaveDocument event. However it seems that it is not being triggered at all.
<xp:executeScript script="#{javascript:setField(document1, 'cCustAddr1_fi', 'test');}">
</xp:executeScript>
This is our basic script. All the setField() method does is use replaceItemValue to try and set the field. However it seems that QuerySaveDocument is not even being triggered since we can write pretty much anything and the document will still save without problem, even if it would be impossible to execute.
We have also tried using a simple document1.getDocument().replaceItemValue() script, but again I dont think it even attempts to execute. Our documents save perfectly fine too,
Do you see any reason for this, are we doing our saving wrong, or should we be attaching data onto the document in another way?
Thanks.
Your other question on Unplugged (Using other dialog controls in iOS) suggests that you are using the Unplugged Mobile Controls project.
If that is correct then my comment above applies - the querySaveDocument event won't get fired . You can look at the code in UnpSaveDocument.xsp and possibly add your own SSJS code to that.
Alternatively, if you want an additional item created on your back-end Notes document then you should just be able to add a hidden field to the UnpFormEditor that is bound to the document1 data source and using the relevant item name you want.
I have been having lots of trouble with this one. I need to have an NSViewController and an NSView pass integer's to a specific document. I really want it to pass the data to the document represented by the key window (I hope that makes sense), but the way I am doing passes the data to all of the open documents.
I am using a document based application, from the Xcode template (Cocoa application with the "Document based application" box checked. Is there any way to do this?
I did not post my code because it really is too embarrassing. Basically, I have a "getter" method in the NSViewController, but I still have not thought of a good way to pass the data back. I ended up with hundreds of lines of code that are supposed to make the document pull the data back with another "getter" method, but they don't do anything.
Is there any documentation on this?
The key window may not have a document behind it, it is just the window that will receive events first, I think what you may be after is -[NSApplication mainWindow] which you can get the window controller for and from that the document, alternatively you could observer the NSWindowDidBecomeMainNotification to keep track of which window is now main or you could use the method -[NSAppliation orderedDocuments] to get the front document. Personnaly I like the NSNotification but there may be resins you prefer one of the other methods.
I'm writing an intranet ASP.NET page using VB.NET. I've run into a particularly nasty problem dealing with handling file uploads. I'll do my best to explain the problem, and perhaps someone can help.
My problem is almost a duplicate of this one, or this one, except (other than the filename) I don't care about sending the file to the server until the other data has been reviewed.
Here's the situation:
Joe Q. Dataentry inputs some data into several fields. The first 3 are drop down, and when he changes the selection, a postback event is fired that queries a database for valid entries for the other drop down selections. After selecting the values, he inputs some other data, chooses a file to accompany the data and clicks the "Update" button. When he hits the button, it fires a postback event that sends the current data to the server to be validated. The data will create a change in the database, so he is presented with a view of the current state, and what it will look like when his changes are made. He can now either confirm or cancel the operation for whatever reason.
Part of the data he will see involves the extension of the file which may be a PDF, or could also be some image file or other document.
Now here's where my problem is - on each postback event, the fileupload dialog is cleared. I was getting around it by creating a temporary file on the first postback and then renaming if he clicks OK or deleting on Cancel... but I need to do a variety of things, based on the previous state of data and the filename. I've tried to keep some session variables to retain the filename, and that works OK for just renaming the file, but for what I need to do it gets unwieldy.
What I want to do is be able to have the postback event to present the changes, and then when the user clicks "OK", submit the file. Is there any possible way to do that?
One of my thoughts was to do some of the validation client-side (I'm already re-validating server side so I'm not too worried about data security there), but I don't know how I could get the information from the database query.
Thanks for any help, and reading my slightly convoluted story/situation!
EDIT:
It appears that what I want to do is prevent a certain button from firing a full postback. Is there any way to do that?
EDIT II:
I have an update panel on the page already - is there any way for the button to only post what's in the update panel?
What you might want to do is place your drop-downs inside of an ASP.NET AJAX UpdatePanel, and keep your file upload control out of that.
Your update panel will do the post backs and allow your validation logic to happen without submitting the file, then when you hit your final "Save" button (which is also outside of your UpdatePanel) the entire form will be submitted back and you can work with your file then.
It may be very simple, but I cannot find it:
I have three windows in three separate NIBs in my application. One is opened when a new document is opened, the other two can be opened from the program's window menu.
The problem is: two windows (in them the one that is opened at the beginning) accepts the normal keystroke as for example command-s for save, and the other one does not and gives a warning sound instead. I cannot figure out the difference between the two windows or their controllers. I know it will have to do with the responder chain, but I am left clueless.
Any ideas?
Check to make sure that the window's delegate is set to the window controller, and that the window controller implements -saveDocument: (or whatever action the Save item is connected to).
Windows don't respond to key combinations. Menu items do. In response to being pressed (whether using the mouse, using a key combination, or using Accessibility), the menu item sends its action message down the responder chain.
You get a beep when nothing in the responder chain responds to the action message.
Assuming that this is an NSDocument-based application and you've started Apple's doc-based-app template, the menu item's action is saveDocument:, and the NSDocument object is the object that responds to that message. When your document windows are active, their documents are in the responder chain, so the menu item that sends that action message is enabled. When your third window is active, the document is not in the responder chain; nothing else responds to that message, so the menu item is disabled.
This problem isn't specific to Save—it affects all action messages that should go through to the document object. One important other example is Print: The user will probably mean to print the document, not the third window.
You've probably made this third window a kind of window that exists as a peer to the other windows. Besides this responder-chain problem you're having, the user will also probably not realize that they have left the document; they expect to still be able to do document things. Consider making it a utility panel instead.
If you really do have a good reason to make this window whatever kind of window it is, you'll need to keep the last-active document object in the responder chain when this third window becomes main, while at the same time handling the case where the window becomes main because a document window (possibly the last one) has closed.
Well, it turns out that I implemented the third window in a way where I created it with its controller using initWithNibFile, ran a procedure in the controller and then sent it a [window close] command because I did not want it to appear on the screen yet. That somehow took it out of the document-associated window, no idea why. No I migrated that specific called procedure into the document controller itself, treat the window like the second window and voila, it works again.