I am getting the above mentioned exception in PointerPressed that too only in the case of MFC application hosted using XAML Islands. In normal UWP application it is working fine. Essentially no other Pointer events are fired in this scenario (Released, Canceled, CaptureLost,Exited etc) but we need to handle some UI changes in PointerReleased.
Kindly suggest any workarounds for the same.
Related
I am attempting to port the DirectX12/XAML UWP template over to a C++-WinRT version... where EVERYTHING is done via C++-WinRT and I can turn off CX. I'm currently stuck on how to ResizeBuffers on the swapchain. Before resizing the buffers I have to release all the buffer references. In C++/CX ComPtr there is Reset() method to release reference of the renderTarget buffers, but in C++/winrt com_ptr no such Reset() method exists and if I set renderTarget to nullptr in order to release it, it throws an exception shown in the Screenshot below. And if I don't set the renderTarget to nullptr then exception is not thrown but the swapChain is also not resized.
Later I also tried it using the wrl::ComPtr and the Reset() method it is still throwing the same error. Does anyone know the correct way of resizing the swapChain in DirectX12?
Screenshot of the code and error
You can't use a "fail-fast" error handler like ThrowIfFailed for ResizeBuffers or Present. Both return meaningful failure codes at runtime you must handle.
Specifically both can return DXGI_ERROR_DEVICE_REMOVED or DXGI_ERROR_DEVICE_RESET and you need to handle it. In fact, in the UWP environment, you will see this happen at start up so you must handle it--some 'classic' Win32 desktop apps just ignore it and crash at weird times like when Windows Update updates a driver while the game is running.
For details on handling 'lost-device' (which is really 'device removed'), see DeviceResources .h / .cpp.
See also Microsoft Docs which is written for DirectX 11, but all the equivalent stuff has to happen for DirectX 12.
I have console applicaiotn that currently uses CAsyncSocket.
I need to implement SSL so after some searching I found this project: http://www.codeproject.com/Articles/3915/CAsyncSslSocketLayer-SSL-layer-class-for-CAsyncSoc
For some reason same simple code that works fine on GUI code does not work in console app.
Has anyone exp. with CAsyncSslSocketLayer ?
Thanks.
CAsyncSocketEx uses a window as a sort of cheap thread to handle the event notifications that come from select(). Unfortunately, if you don't have a message loop, then the window which it creates will not receive these events.
http://support.microsoft.com/kb/90975
This article explains that a call to CreateWindow() needs to be called from a thread which has a message loop. And if you don't, then anything sent via PostMessage() won't get there.
I've recently started to tinker with this -- I want to remove the annoying hidden window and replace it with a normal thread. Their code relies on WSAAsyncSelect() in order to receive socket events... to a window. Yuk!
It's been a while since I had the same problem, but if I remember correctly, to use CAsyncSocket in a console app you need to add something like DECLARE_CONSOLEAPP (first two links shown below) to your console app. This should give your console a message pump to generate the socket notifications (OnReceive, etc.) GUI apps have these pumps but console apps don't, generally. The third (msdn) link below might also apply, it has more info and a different way.
If these still don't work, you should put breakpoints in your socket code and make sure your socket isn't instantiated in a thread or callback other than the main console app (the one that now has the message pump).
I think googling around for 'CAsyncSocket WinApp' or 'CAsyncSocket console app' would show more.
http://www.codeguru.com/cpp/misc/misc/consoleapps/article.php/c243/Console-app-using-MFC.htm
http://troels.knakkergaard.dk/code.htm
http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/a6f1b72a-21d8-4046-a3dc-d7d29ece2ef6
Hi I am trying to load page into Air using the htmlLoader class. What event listener will I need to attach to the HTMLLoader class in order for it to notify me when the page can not be loaded.
Any help much appreciated
The only event fired directly from the HTMLLoader that appears to be error handling is:
uncaughtScriptException
Signals that an uncaught JavaScript exception occurred in the HTMLLoader object.
however when you call send and pass along a URLRequest you should be able to add listeners to the Loader, from an example in the docs, this should be good enough:
dispatcher.addEventListener(Event.COMPLETE, completeHandler);
dispatcher.addEventListener(Event.OPEN, openHandler);
dispatcher.addEventListener(ProgressEvent.PROGRESS, progressHandler);
dispatcher.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
dispatcher.addEventListener(HTTPStatusEvent.HTTP_STATUS, httpStatusHandler);
dispatcher.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
in your case I'm guessing you'll need to use the HTMLLoader instance's loaderInfo property and add the listeners there.
Hope this helps.
Background
I'm using UKCrashReporter in my app.
I've installed my own Uncaught
Exception Handler.
I'm setting up the
managedObjectContext of the object
activeItemController in
applicationDidFinishLaunching (1)
The Problem
If the managedObjectContext method throws an exception, the crash reporter dialog box only flashes up before the app crashes and so the user never gets to report the crash.
I want my app to continue only after the crash has been reported, not whilst the window is showing.
What I've tried
If UKCrashReporterCheckForCrash()
were an objective C method, I assume
I could call
performSelectorOnMainThread:waitUntilDone:YES
but it's not.
I've looked at some other Stack
Overflow questions about using
Conditional Locks to pause apps,
but I can't understand how I'd use it
for a C function.
How would I go about doing this in a nice way? Do people have any advice
for me? Any responses would be much
appreciated.
The Code
// In app delegate
-(void)applicationWillFinishLaunching:(NSNotification *)aNotification {
UKCrashReporterCheckForCrash(); // A C function which then creates a window if
// it detects a crash has happened.
}
-(void)applicationDidFinishLaunching:(NSNotification *)aNotification {
[activeItemController setMoContextDisk:[self managedObjectContext]];
[activeItemController setMoContextMemory:[self managedObjectContextMemory]];
}
Update 1
I've been asked for more details on what I'm trying to do, so here goes.
The bug that triggered this thinking was an exception when merging managedObjectModels. My app got caught in a loop printing "Uncaught exception" to the console every few milliseconds.
And when I installed the uncaught exception handler before this exception happened, I'd get the described behaviour - my app would fire up, display the crash report dialog briefly, then continue to load and crash again.
Summary - I want to be able to handle errors that happen on startup.
(1) I'm not using bindings to do this, as I thought bindings would make testing the class more problematic.
I think your problem is with thinking of it as "pausing" your app. Think of it more as a different initial UI state. Your attempts to block the run loop will prevent any interactive window from ... well, being interactive. :-)
Your best bet is to show your main UI (and connect data sources, etc) only if the "am I prompting the user to submit a crash report" method says "no, go ahead and start normally". Otherwise, show your window and, when the user sends or declines to send the report, close the window and ask your app controller to continue the normal startup.
I looked at UKCrashReporterCheckForCrash() and it doesn't appear to create a window of any kind. It merely submits the crash. Could you describe what you're doing with more detail?
I have a problem which is also related to AppDomain's and Windows messages.
A web page to be hosted in Internet Explorer that would contain a .Net WinForms UserControl derived control - HelloWorldCtl. This control is inside a C# written assembly - HelloWorldControl.dll. The control uses code from another assembly that is written in C++/CLR - HelloWorldLibCPP.dll.
HelloWorldCtl loads HelloWorldLibCPP.dll and calls code that would create a Win32 native window and places that window in HelloWorldCtl's area.
Navigate to the web page, HelloWorldCtl loads, I can see it as well as the native window in the center of HelloWorldCtl's area.
Both the C# control and the native window have some message handlers and the messages are all working fine and reaching both the C# control's window and the native window; mouse clicks, re-paints and so on... However, some of the message handlers of the native window need to call methods on the C# control which is the parent of the native window. This is done using an interface that the C# control implements and which the native window holds a reference to by storing it in a GCHandle (from System::Runtime::InteropServices.) I used the gcroot<> template for the GCHandle.
The failure is happening at this point when code in the native window is trying to use the GCHandle to call any method on the C# control. (The c++ code is compiled as managed code with /clr.)
The exception that is thrown is :
"Cannot pass a GCHandle across AppDomains"
I put some debugging code to display the Id and FriendName of the CurrentDomain in both the C# and the native window and I found out that these AppDomains are not the same.
During the creation of the native window, the CurrentDomain is the same as that of the C# control, but when the native window receives messages and those messages are handled, the CurrentDomain is different from the C# control's.
Can this situation be changed? Is it possible to have both the native window messages hanlder run in the same AppDomain as that of the C# control?
Any other suggestions perhaps?
Thanks,
Roger
I have actually found a solution for the problem in question indeed. I successfully implemented my code in a similar fashion to what is described in the following post from the "Thoughts from Mirality,
Random thoughts and musings from Miral at Mirality Systems" blog under the subject "Unmanaged callbacks across AppDomains".
Good Luck,
Roger
http://lambert.geek.nz/2007/05/29/unmanaged-appdomain-callback/