I have a program that displays an NSSavePanel as a sheet. Mostly it works.
However, it can get into a bad state after I display an ordinary window as a sheet.
In that bad state, the code that normally displays the NSSavePanel instead just beeps.
I can put a breakpoint on NSBeep and confirm that NSBeep is being called, but there is nothing useful in the stack trace (running on macOS 11.5.2) to suggest what the problem might be. No error message is printed in the debug log.
I might guess that when I displayed the window as a sheet the sheet was not fully cleaned up, but I can show the window as a sheet any number of times without any obvious problem.
I found the answer. When I displayed the ordinary window as a sheet, I failed to call endSheet:. I only closed the window. Odd that many things are insensitive to this error. Even displaying an NSOpenPanel worked, but not NSSavePanel. I suppose the beep might be related to some event delivered to the owner window while it was "busy".
Related
is there some way to repair broken functionality in ms access, like recompiling the thing?
I have a button on a form that is supposed to run vba code when clicked. The button no longer works, after like a couple of months. Except for the button getting focus nothing happens. I have tried the compact and repair option in access with no luck. The code works fine btw. I have made a new random button somewhere else on the form and literally copy pasted the vba code from the on_click event of the broken button to the new one, and on the new button it works perfectly. No problems at all. The old one, however, nothing. No matter what I do. I deleted the vba code in the on_click event, saved, closed and opened access again, then reentered the code. Still nothing. I tried removing certain functionality from the button by removing line by line, trying to see if any one line is the issue. Nothing again, no errors are being displayed, I don't think the button even runs the vba code at all.
In case someone wants to look at the code:
Private Sub Befehl107_Click()
[NavigationSubform].Form![stoffe_abfrage subform].Form.FilterOn = False
[NavigationSubform].Form![stoffe_abfrage subform].Form.Requery
Me.FilterAlleLink = "Alle"
Me.FocusDummy.SetFocus
End Sub
The button basically turns off the filter on a subform, requeries the form, sets the value for a textbox on the local form, and then gives focus to another textfield. Nothing complex really. I have 3 more buttons of the same type on my form that manage different filters for the same subform with almost identical code, they all work fine. Just this one broke.
Again, the code works fine if I make a new button, but on the old one it does not do anything.
Obviously I can just replace the button, but that would be annoying if down the line there is other functionality referencing it etc. So I was wondering if anybody encountered a similar problem and has a solution. Given that I have only worked with access for like 2 months total and already have this issue I hope there is some way to repair this more quickly, since I am now assuming that this will happen more frequently. Not sure though, maybe someone with more experience knows if this is common.
Edit: I just checked if literally copy pasting the broken button itself works and yes. I copy paste the broken button somewhere else, then copy paste the vba code from the broken button to the copy, and the copy now works...
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.
I'm not even sure how to ask this question, but here goes. The design view of my windows forms object now crashes with the following error:
The control DevComponents.DotNetBar.Office2007RibbonForm has thrown an unhandled exception in the designer and has been disabled.
Exception: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index
Stack trace:
at DevComponents.DotNetBar.Office2007RibbonForm.WindowsMessageStyleChanged(Message&
m)
at
DevComponents.DotNetBar.Office2007RibbonForm.WndProc(Message & m)
When the error page pops up, it is this:
I can't think of anything I did before this happened, which is very frustrating. The last thing I did was this:
Add Button on Ribbon Control
Double-Clicked the button to add code
Realized I forgot to name the button, so removed the event code
clicked back on the form tab and BAM. Error.
I tried the following to fix:
Went back and did an undo on the code (re-added the event for that button). But didn't help.
Edited the Designer.vb file to remove that button entirely. Still didn't help.
I thought about pasting my designer code here... I will if that makes sense, but it is so huge I wasn't sure if that was worthwhile. Maybe the above error makes sense to someone besides me???
**** EDIT: Forgot to mention the application runs fine. Just can't edit the form anymore.
OK. I found it. For some reason the form duplicated the style on the ribbon control. Even though the error didn't seem like that one.
FYI - I just kept commenting out stuff in the designer and then trying to launch the form until the error went away. When I finally got to the ribboncontrol, I saw that there were 2 statements:
'Me.RibbonControl1.Office2007ColorTable = DevComponents.DotNetBar.Rendering.eOffice2007ColorScheme.Silver
and
Me.RibbonControl1.Style = DevComponents.DotNetBar.eDotNetBarStyle.StyleManagerControlled
As you can see, I commented out the first one and everything worked.
This is a distilled form of a problem I'm having with a real application. Under certain circumstances, the initialization/activation code of a userform might result in the form losing its ability to correctly process tabs and enters: rather than switching between controls, these keys are passed to the controls themselves (even if they have TabKeyBehavior set to False). The simplest way I've found to systematically reproduce the problem is by having this at activation time:
Private Sub Userform_Activate()
Application.DisplayDocumentInformationPanel = True
End Sub
which seemingly causes Excel to "half-steal" the focus from the userform, so to say: the userform remains focused but tab/enter processing fails. The problem immediately goes away by switching to some external app and getting back to Excel (pressing ALT+TAB twice, for instance.)
Steps to reproduce the problem:
Download tabnotworking.xlsm.
Open tabnotworking.xslm.
Enable macros.
Click on the "Launch UserForm1" button.
UserForm1 is displayed and the textboxes accept input from the user, but tab/enter does not work as expected.
Press ALT+TAB twice or click on some external app and get back to the form: now tab processing works OK.
Once tab/enter processing has been restored, further usage of the form, including relaunching it, seems to work OK (most of the time). To reliably reproduce the problem again, close the book and start from step 2.
There are numerous references on the Internet to problems with tab processing seemingly related to this one, but no actual solution. Any clue on what's happening and how it could be solved? Thank you,
I have a very strange bug, which I believe is caused by some code we have executing, but I'm not sure where.
We can reproduce it to the point it happens whenever we click Tab, but short of putting a break point at the beginning of every method in the project to find out what is executing.
Is there a way to set visual studio to break whenever anything executes?
For those curious about the problem, every now and then, we have a few Rich Text Boxes that refuse to lose focus. You can't click out of it or tab out of it.
We have no On Validation or On Text Changed events attached to the control, and believe it's an event attached somewhere else to something we just aren't noticing.
You can set a breakpoint in the WndProc method, which will run whenever Tab is pressed.