I'm writing a simple Cocoa Application, no core data or multiple document support. Running on a Mac Pro, OS X 10.6.6, Xcode 3.2.3.
I have reduced my application to the following code in my AppDelegate class:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSOpenPanel *openPanel = [NSOpenPanel openPanel];
[openPanel runModal];
return;
}
From within the debugger, I will run my application. As expected a somewhat not-to-useful OpenPanel will appear. I will click Cancel and it will disappear. All this is as expected. When I click [Command + Q] to Quit the application, the UI will go away but the debugger will indicate that the application is still running (as does the console output).
Based upon all the information I'm reading, I should not have to do anything else in order for this to run right. I've downloaded several examples on the Open Panel's usage but most use the deprecated methods of opening modal giving additional information as parameters. FWIW, I tried those methods and am still seeing the same result.
One last item, when the Open dialog appears, just for an instant I see a message box asking me something to the extent if I want my application to receive incoming connections. The dialog quickly disappears. I don't know if that is part of my problem or not. [Update - this deals with my Firewall being turned on.]
Yes, I'm fairly new at Objective C but not at programming in general. Any words of wisdom is greatly appreciated!
2011.02.07 - Update:
I have walked the debugger line by line without incident. There is no indication of any program failure in the console window.
I say that the debugger is still active after [Command + Q] because the Stop Process toolbar button is still enabled as is the Break button. Further the console indicates that after I tell the application to terminate (either via the menu or key command) that it is still running. The following is the Complete console output from start of run to after I Quit the application.
Program loaded.
run
[Switching to process 62370]
Running...
The Activity Monitor (system tool) will show my application terminating (no longer shows up as a process) but the Debugger will still not transition to "edit" mode - if I tell Xcode to run the debugger again, it will ask me if it's OK to Stop the current debugging session. If I was in Windows I would start looking for background threads keeping the process alive but as far as I know, NSOpenPanel should not be doing something like that.
I have further simplified the program to nothing more than creating a brand new Cocoa application and inserting the code snippet above - no other additions to the template project or updates in any way.
And lastly, when the application is run under the Leaks Performance Tool, everything runs fine when the panel is created but never used. When created and actually used though, at the end of the run I will get the following message in the tool "insufficient task_for_pid privileges (leakagent64)". Googling this hurts. If I read it right, the debugger does not have sufficient permissions to fully kill the target process ??? Now that sounds stupid but ... It does not make sense!
Another update - I just downloaded and ran FunHouse, one of the SDK sample applications that also uses NSOpenPanel. Well don't I feel special. It exhibits the same exact behavior. So from this I conclude either Apple has a bug in their code, my machine is special and messed up, and finally, it is Not my code that is at fault. That being the best part. Tomorrow, I will use a friends Mac and see if the same behavior is exhibited on his box.
This is just too weird.
I rebooted my box, took it to work and found it worked like a charm! I will assume this is fixed and has nothing to do with any other connected devices at home as compared to at work.
If it re-exhibits at home, then it is a network/device issue. Thanks all for your inputs and suggestions! Very much appreciated.
What, specifically, does the debugger say? It's possible that your program crashed, so the debugger is showing you information about the crash.
What if you omit any attempt to run an Open panel?
Related
Okay, I have had the most aggravating problem with OpenFileDialog1. I have a program that I've been using for some 8 months, and in the past month, the program has begun to hang randomly when utilizing the OpenFileDialog1.ShowDialog() function. I have already read through all of the other posts about multi-threaded vs single threaded application. This did not fix it. Enabling the "Show Help" button did not fix it. I am mostly at a loss. here is a thorough walkthrough of the bug:
Run the application. I can always use the Open File button a few times with no problems. It freezes randomly after the program has been running for awhile.
The freeze happens after I push the ShowDialog button, and never displays the Open File Dialog window. The entire program locks up and hangs. If I pause it, Visual Studio doesn't show an error. It underlines the OpenFileDialog1.ShowDialog() in green, which is very odd.
I have found a way to break the freeze. Simply run a second instance of the program and use the OpenFileDialog function. As soon as it loads the file in the second instance, the first instance unfreezes. However, this is not a fix.
The only thing I can think of that may be causing this is the program also uses a WebBrowser1 control. It only seems to happen AFTER the WebBrowser control, which is on a seperate form, not the main form, has been initiated and utilized. Does this make any sense at all?
Thank you for anyone who can help me. I am about to tear my hair out.
Debug your program with dnspy, And when the software freezes, you will be able to see within the dnspy the actual code even if it is in a third party DLL.
I have solved this problem. It was quite unsolveable based on my description above, but hopefully I will help someone with this solution. The error is related to using the IE11 Emulation Control (11000) in the WebBrowser1 control. For some reason this interferes with OpenFileDialog and causes it to hang. I have no idea why. I changed my WebBrowser1 to use IE9 Emulation Control (9999) and the error has gone away. Thank you to those who looked into this. This is a registry entry in HKEY_CURRENT_USER.
I have an App that I inherited in VB6 and have ported mostly to VB.net
When I compile / run the app - it highlights all the files in the current selected folder.
What makes it worse, is it's very difficult to search online as what search terms does one use?
The app was ported to VS 2005 - quite successfully - but this has me stumped...
I have tried commenting out all the code that's run on startup and it still does it, so it must be some sort of background thing...
Any ideas?
I can't find an old version of my app to see if it's changes I have made and I don't know where to begin. See the image:
The top part is before I run the app, the bottom is once the app is running and has focus. I hope it makes sense
Also, if I'm browsing and then run the app, and go back to the browser, when my app gets the focus again, the webpage goes back to the top...
The folder is just an example - Basically when I compile (or later run) my App, if I go to Windows Explorer - when the app gets focus - whatever folder I am in has all its files highlighted. If instead of going to Windows Explorer, I go to a web browser, when the app gets focus the browser goes to the top (similar to Home).
There is Windows Integratio, but I have commented out what I can and still am no closer.
Does this info help?
I found the problem - after going back to the vb6 project and removing everything except for the 5 modules needed to startup and I eventually tracked the problem.
There was some code being called when two edit boxes received focus which called send keys home and end - hence it would go home - select all files to the end. I had deactivated one of the edit boxes to not receive focus and it helped temporarily(obviously until the other box got focus), but since deactivating the send keys when they get focus has helped. Albeit an arbitrary problem, maybe it will help someone in the future..
I'm investigating an issue on Mac OS X 10.8, and I am at the end of my wits. I'm not sure what to do next.
The application is 32 bit and has some Carbon calls in it.
Here is the problem: when I right-click the application icon in the dock, select the menu item "Hide", then, after the application has hidden, I select the "Show" menu item from the dock, and the problem occurs: the main document window does not appear (the palettes and menu do appear).
At this point, the "Show" menu item does not change to "Hide" even though the palettes have become visible.
I expect that the main document window becomes visible when I select "Show" from the application dock menu. Just like other Mac applications.
When it fails, I can make the main document window visible again if I use the App Exposé gesture on the Trackpad to show the document windows and select the main document window.
It works fine if I launch the application from the Terminal or from Xcode. The document window shows and the dock menu item for my application changes to "Hide" as expected. I launch the app from the terminal by navigating to the parent directory of the *.app, and typing ./MyApp.app/Contents/MacOS/MyApp.
It fails when I have launched by double-clicking the application icon in the Finder.
My log messages from the application delegate's unhide functions appear when the application is launched from the Terminal and Xcode, but not when launched from the Finder.
– applicationWillUnhide:
– applicationDidUnhide:
I have looked in the Console.app for any exceptions thrown (or any other messages). There are none.
Update:
To try and debug this, I launched from the Finder, and used Xcode to attach to the process.
I had suspected that an exception was being thrown and when I tested it using Xcode's "Exception Breakpoint" as well as putting a breakpoint on objc_exception_throw (just in case), it dd not break when I hide or "show" the application.
I then thought that I needed to prove that the NSApplicationWillUnhideNotification and NSApplicationDidUnhideNotification were being sent out. They are when I launch from Xcode or from the Terminal, but if I launch from the Finder, they are not.
I verified this by, after attaching Xcode to the application, putting a breakpoint via "Add Symbolic Breakpoint" for:
-[NSNotificationCenter postNotificationName:object:userInfo]
And then, I added a Debugger Command: "po * (id*) ($esp+12)" to print out the first parameter to that selector (the notification name).
Which I found in an answer posted here, in StackOverflow.
Using that, I can see the notifications that are posted after I choose the "Show" menu item. When I launch from Xcode/Terminal, I see the following notifications posted:
NSApplicationWillUpdateNotification, NSWindowDidUpdateNotification, NSApplicationDidUpdateNotification, ** NSApplicationWillUnhideNotification **, ..., ** NSApplicationDidUnhideNotification **, ..., NSApplicationWillBecomeActiveNotification, ...
NSApplicationWillUnhideNotification is posted in this situation.
When I launch from the Finder, I see the following notifications are posted:
NSApplicationWillUpdateNotification, NSWindowDidUpdateNotification, NSApplicationDidUpdateNotification, NSApplicationWillBecomeActiveNotification, ...
It does not send the NSApplicationWillUnhideNotification. Also, when I select "Show" from the Xcode-launched version, I see -[NSApplication _doUnhideWithoutActivation] in the backtrace. Putting a breakpoint for that function when I attach to the Finder-launched version does not result in a break when I select "Show".
Then, I thought to myself, perhaps the application thinks that it is not hidden.
I have a idle event handler, so from there I printed out the value of [[NSApplication sharedApplicaton] isHidden] while I Hide and "Show" the application.
For the problem situation, when the application is not hidden, it prints out NO for isHidden. When the application becomes hidden, it prints out YES for isHidden. When I select "Show" from the dock menu, it continues to print out NO for isHidden. It knows that it is hidden, but part of the application has been activated: the NSPanels and the NSMenuBar appear.
I can see the document window by entering into the application Exposé mode, and clicking the document window will make the window appear, but the dock menu item is still "Show" and isHidden is still YES.
The unhide mechanism works fine for a sample application, so I'm pretty sure that our code is doing something to shut this off.
I wonder what would be different between an application launched from the Terminal compared to an application launched from the Finder?
I had the application log the environment variables using [[NSProcessInfo processInfo] environment] and the only real difference I could see is that PWD exists in the variables for the Terminal application: I cannot see anything in our code that makes use of that.
I had the application log the command-line arguments via [[NSProcessInfo processInfo] arguments], and I do see something different in the Finder-launched version. Both the Terminal and Finder launched versions list the path of the binary as the first argument; the Finder also lists a second paramter, "-psn_0_89445704". I have read online that it is something that Mac OS X adds to command-line arguments for GUI applications and I see it added to the command-line arguments for other applications that Hide and Show properly from the Dock menu.
Do you have any other thoughts that may lead me further towards solving this mystery? Thanks for any help or suggestions!
After working with Apple Engineers in AppKit, a solution has been found.
In our application, we "flush" the event queue for various reasons via this method:
NSEvent* lastEvent = [NSEvent otherEventWithType:NSPeriodic
location:NSMakePoint(0.0, 0.0)
modifierFlags:0
timestamp:[NSDate timeIntervalSinceReferenceDate]
windowNumber:1
context:NULL
subtype:0
data1:0
data2:0];
[[NSApplication sharedApplication] discardEventsMatchingMask:NSAnyEventMask beforeEvent:lastEvent];
The Mac OS X systems sends a "Show" event to the application on launch. Our flush function, which is called upon launch, effectively removes that event from the queue, but the core process part of Mac OS X has its own internal queue that keeps track of show and hide and other types of event types so that it doesn't send repeated messages. (I'll be investigating if this flush is really necessary)
The problem is that when discardEventsMatchingMask:NSAnyEventMask is called on every event, it clears out the events for the application, but doesn't respond to the core process's show event and so core process thinks that it doesn't need to send the show event again.
The solution to this particular problem is to be more selective in which events are cleared. With my new implementation, I do not clear events that will be sent by core process.
/* a bug in Apple's Core Process group forces me to isolate which events should be cleared as
show|hide|activate|deactivate messages get sent by Core Process, but are not _marked_ as
handled and so Core Process thinks that the "Show" event is still pending and will not send
another */
NSEvent* lastEvent = [NSEvent otherEventWithType:NSPeriodic
location:NSMakePoint(0.0, 0.0)
modifierFlags:0
timestamp:[NSDate timeIntervalSinceReferenceDate]
windowNumber:1
context:NULL
subtype:0
data1:0
data2:0];
NSEventMask maskForEventsToDiscard = (NSPeriodic |
NSLeftMouseDown |
NSLeftMouseUp |
NSMouseMoved |
NSLeftMouseDragged |
NSRightMouseDragged |
NSMouseEntered |
NSMouseExited |
NSKeyDown |
NSOtherMouseDown |
NSOtherMouseUp |
NSOtherMouseDragged);
[[NSApplication sharedApplication] discardEventsMatchingMask:maskForEventsToDiscard
beforeEvent:lastEvent];
As the "show" event is not cleared on launch, show and hide work now!
A special thanks to KF of Apple!
This technique won't fit in a comment, but I might suggest getting up-close-and-personal with DTrace. I suggested in the comments above to subclass NSWindow and put NSLog statements in the -orderOut:, etc. methods. However, using DTrace for this would likely be far more effective - although, as you will see, it will still be useful to know the address of the objects you will be observing - the upside is that you won't litter your code with a bunch of NSLog statements.
The simplest script might be:
#pragma D option quiet
objc$target:NSWindow:-orderOut?:entry
{
printf( "%30s %10s %x %x\n", probemod, probefunc, arg0, arg1 );
}
and would be called with the process id of the application by doing something like:
sudo dtrace -s dtrace_window.d -p9434
In this particular case, arg0 will contain the address of the window. Unfortunately, it is apparently non-trivial to obtain the title of the window or even the contents of a NSString from within DTrace, but may be worth the effort. I do have a question here and here to see if anyone knows to do either one of these things. (If you can get the title of window, you can set up a map from the address of the window to a string.)
It would be easy to attach probes to any and all methods, functions, etc. you think might be involved so you can try to "follow the event" to resolve this problem.
So, ultimately, I would suggest to just keep adding DTrace probes until something provides the required hint resolve this problem.
VS2012's default C# "Metro style" project templates include code in App.xaml.cs (in the OnLaunched override) to restore the application state after a suspend-and-terminate. This code only runs when LaunchActivatedEventArgs.PreviousExecutionState is Terminated, i.e., "The app was terminated after being suspended."
How can I force my app to be suspended and terminated, so I can test this suspend/resume functionality in my app?
Things I've tried that don't work:
If I use the "close app" gesture (drag from the top of the screen to the bottom), then the next run's PreviousExecutionState is ClosedByUser.
If I kill the app -- either using Task Manager, or (if I was debugging) with the "stop" button on the VS toolbar -- then the next run's PreviousExecutionState is NotRunning. This is true even if Task Manager showed the app as "Suspended" before I ended task, so clearly it's more nuanced than the description of "terminated after being suspended".
You'd think I could just switch away from my app, and then open lots of other Metro-style apps until my app eventually gets kicked out. But even if I open every single Metro-style app that ships with the Windows 8 Release Preview, that's apparently not enough memory pressure to make Windows terminate my app. (I assume Windows would be less likely to terminate an app that was being debugged, so I launched my app from the Start screen -- no debugger -- before I tried this.)
It does appear that, if I switch away from my app and type into a StackOverflow window for several minutes, that my app will eventually get terminated, so perhaps there's a time-based component to it. But if I have to wait five or ten minutes every time for my app to terminate, that's a pretty slow testing cycle.
Given that this is something developers will have to test, you'd think there would be a nice, easy way for a dev to force an app to suspend-and-terminate. Is there some kind of stress-test app that comes with Visual Studio that will force enough memory pressure? Is there some menu item in Visual Studio that will force termination of my app? How are we supposed to test this?
In Visual Studio 2012, when you're debugging, there are "Suspend", "Resume" and "Suspend and Shutdown" buttons. By default, you should see the buttons while you are debugging your app. See this article for more info on debugging process lifecycle.
I had trouble finding the Suspend control because VS wasn't showing a second row of toolbars for me. As it turns out, this is on the "Debug Location" toolbar. Make sure you have this toolbar turned on and then you should be able to find the Suspend control (and it does work to solve the OP's problem).
If they don't show by default, go to TOOLS -> CUSTOMIZE, and under the Toolbars tab, check the box that says "Debug Location"
I was looking for VS 2013, just in case others came for the same reason.
Source:
http://blogs.msdn.com/b/visualstudio/archive/2012/08/23/new-visual-studio-2012-debugging-features-for-the-windows-8-app-lifecycle-model.aspx
a busy cat http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-92-metablogapi/2210.image_5F00_thumb_5F00_1FBA9C1E.png
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?