Thank you for reading at first.
I designed a WPF application which rehosted the Designer, Toolbox and Properties of Windows Workflow. My Idea is really simple that I just want have visualization at runtime about my workflow and design them in the runtime as well.
ISSUE:
Now I try to Invoke a Method of a class under the same namespace of whole application. The class is called MyTwsClass. Please have a look below:
It is extremely Simple. The TwsClass is from a Reference ActiveX of Interactive Brokers Trading Software. This ActiveX simply provide the method and event for you to communicate with your account. Alright, I implement the MyConnect() method as you can see and this method simply set up some string and int variables to be parameters of connect method from TwsClass. I noticed that I could not set MyTwsClass or MyConnect method as static.
Now, at runtime designer, I try to invoke the MyConnect method. First of all, picture below:
Since MyTwsClass could not be a static class with static method (I guess it is because it inherits from the ActiveX class TwsClass, I am not sure as a newbie.) So I wanna invoke the instance method. It has no complaints before running the workflow. After running this, I expect that I should be able to connect to the API of the trading software.
Now I run the workflow:
Right after clicking the running button, it runs and I got pop up window to tell me that APP has crashed with exception code C0000005. If I click the close option, my WPF application will be closed. BUT before I close it, I could see that ACTUALLY the crashed WPF actually connected to the API as you can see in picture above to tell me that 1 is connected......
I tried my best to check this problem on Internet. I am kind of have sense that it is all because of some issue within Interop or COM process between my WPF and the reference ActiveX as the crash window indicated that the TwsSocket.dll is the reason.
But I really could not figure out further.....
Related
My UWP app goes into UI freeze state sometimes and I don't know why。 I've checked the code about view model and async-await calls. And I've tried to use the performance profile tool in Visual Studio to get timeline but it only shows the time and duration time about the UI freeze. I have run out of ideas now.
I tried the dotTrace but it seems that I cannot use it to profile UWP application. Even I " disable the Compile with .NET Native tool chain option in Visual Studio (via the menu Project | Properties... | Build) and rebuild the project."
https://learn.microsoft.com/en-gb/visualstudio/profiling/profiling-feature-tour?view=vs-2019
There are many reasons for UI freezing, including code endless loops, asynchronous methods are not handled properly, program errors, etc.
Most of them occur in asynchronous method processing and UI rendering.
When calling asynchronous methods, use the async/await keywords, like:
//define
public async Task asyncMethod()
{ }
//use
await asyncMethod();
Reduce resource consumption when rendering a large number of data templates through virtualization.
If you have a large list to render, if virtualization is not enabled (referring to controls with virtualization, such as ListView), or used, but the conditions of virtualization are destroyed (such as adding ScrollViewer outside ListView ), This will also cause the UI to freeze and will not return to normal until the list is rendered.
Please check your code for the above problems, or provide a minimal reproducible demo so that we can analyze where the problem occurs.
Best regards.
I would suggest you try to use the Visual Studio debugger to find out what the code is doing.
First, make sure that you are set "Debug" mode and that the debugger is going to run on "Local Machine" (there are other options here, but I'm trying to keep things simple).
Then, click on the "Local Machine" button to run your app using the debugger.
Once your app freezes, click on Debug-Break All:
After that, I suggest you use the various Debug commands to further debug your application.
For example, you can use the "Call Stack" menu item/window to view what your code is doing. You can also use the "Threads" menu to see what threads are running. If you have suspect areas in your code, you might consider adding System.Diagnostics.Debug.WriteLine() statements to print out informative messages, and then use the "Output" menu item/window to see what is happening.
If your app first freezes, and then crashes after some time, then this could be because your tasks don't have correct exception handling. You might consider adding an UnobservedTaskException handler to your code to help you find this problem.
I am making a windows phone 8 application and in the designer view in both blend and VS I get "Unable to determine application identity call" error as a dialog box.
From what I read on stack this is propably because of the Isolated Storage is getting run and the designer can't handle it.
I am wondering is there away I can get some line numbers or something where the errors are happening instead of having to manually go through the code?
By the time you see this message box it is already too late, the exception was caught and handled. You have to catch it when the exception is raised. Which is not so easy to do at design time.
One technique that's worth a shot is to use a debugger to debug Visual Studio itself. Start it again and use Tools + Attach to Process. Locate the first devenv.exe in the list of processes and select it. Set the Attach to: setting to "Managed (v4.5, v4.0)" and click OK. Let it trundle to find the PDBs (takes a while). Debug + Exceptions, tick the Thrown checkbox for CLR exceptions.
Switch back to the original instance of VS and do whatever you did before to trigger the error. The 2nd instance will break in when the exception is thrown. Which some luck you'll see your code on the Call Stack window. If the debugger doesn't break then repeat the exercise but attach to XDesProc.exe, the XAML designer. Good luck with it.
Isn't this
Unable to determine application identity of the caller?
or
Getting Unable to determine application identity of the caller Error
are the same topic????
Don't know, just asking...
Sorry for any inconvenience..
Just answered in my basic question.
I'm afraid, i don't know how to get exact string number, just keep in mind that Designer cant have an access to the IsolatedStorage and check all places where you're working with IsolatedStorage. Basically, what you need to do is to add to all constructors a lines
if (ViewModelBase.IsInDesignModeStatic)
return;
If you're working with MVVM Light, or
if (System.ComponentModel.DesignerProperties.IsInDesignTool)
return;
which is pretty the same but without MVVM Light.
Also, i edited my answer there.
We have a legacy VB6 application which has worked just fine on Windows XP Professional SP 3 until just recently when we added an IE frame control so that we could display static local HTML files on a form. And, it works fine until I go to close the application. And, then it reports the following error message (consistently):
Faulting module ntdll.dll, version 5.1.2600.5755, stamp 49901d48
Here's the reference in the Visual Basic project file:
Object={EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}#1.1#0; ieframe.dll
And we use it by performing the following actions:
Development machine is running Win7 + Vb6 IDE.
Add a component reference to the "Microsoft Internet Controls" located at C:\Windows\SysWow64\ieframe.dll
Place a control on the form at design time.
Show that form modally by calling Form.Show vbModal The error happens when I use the default form instance frmMyForm.Show vbModal as well as when I use a local instance Dim MyForm as New frmMyFormMyForm.Show vbModal
Call WebBrowser.Navigate "staticPage.html"
When the user presses a button, the button click event returns the user choice and the form is disposed of.
Exit the application -- Here's where I get the error.
I've been looking all over the web, and haven't been able to find a whole lot of people still trying to use VB6 in this way. So, I'm wondering if someone might be able to help me on stackoverflow. Any help is much appreciated!
[Update] And, the plot thickens. I made a sample application with just that web component in order to make sure that it was causing the error. But, I didn’t experience the error when it closed like I was when exiting our existing/legacy vb6 application. I'll do a bit more investigating.
A follow up to this in case any runs into the same issue (the original poster and I were coworkers at the time)...
The application was using the VBCorLib library, and some of its string manipulation classes utilized direct memory access incorrectly. Read more at this VBCorLib forum post.
It turns out that the issue was that I was trying to delete the temporary file that the browser had loaded. It works now that I've moved that delete file code to the form unload event.
I'm working on a little macro record/replay tool which can automate a few very old Visual Basic 6 GUIs we have. To do so, I'm identifying the controls by their name (the value of the name property of a control, that is).
One part of this tool needs to determine the name of a control given its HWND. For newer Visual Basic applications which were done using VB.NET, I can use the WM_GETCONTROLNAME window message. This works nicely.
However, this message is not understood by older windows. Is there any way to do this for controls of Visual Basic 6 applications? A solution which does not require being in the process of the GUI would be preferrable, but if I had a solution which only works inside the GUI process then that would be acceptable as well (since I can do the injection myself).
UPDATE: One thing I just tried, this moderate success: I used the AccessibleObjectFromWindow to check for implementations of the IAccessible interface of the object which shows the given HWND. In case I get an implementation (it seems that many [all?] Visual Basic controls implement this interface), I use the accName property to read out the "accessible name". Sometimes this does yield a useful string, but usually it doesn't.
I believe the only way would be getting inside the process and obtaining a pointer to the Form object, yet I have no idea how to do it from outside.
Is it possible you add support for the WM_GETCONTROLNAME to those older applications?
Or maybe, you could identify the controls by some other, natively-available properties?
Other that that, as Raymond is saying, there isn't much you can do.
Can you modify the vb6 apps? if so in each form load event you could iterate me.controls and use the SetProp(ctrl.hwnd, "MYNAME:" & ctrl.name, 0) api to add the name to the window's own property list, then in your other app you can EnumProps(ctrl_HWND) looking for the one that begins with MYNAME: and parse out the value.
I am trying to build my own little toolbox for Vista.
One of the features is a "window placeing tool" which places the windows at saved position. Another tool I could imagine are extensions to firefox or thunderbird...
For these tools to work, I need them to be able to capture "Events" in Vista.
To give you a concrete example:
Explorer Opened New Window
User started Firefox
Mouse moved
For the mouse case, there are some examples for C#.
I also know about the directory watcher, nice little helper.
Want I now need is the "new window opened event"
Any idea how to monitor this, without iterating the current window list every 5 seconds (I already know how to get Windows using the DLLImports, and getting Processes using managed code. But I have no Event when the explorer process opens a new windows)
Thanks for your help,
Chris
What you're talking about doing is not simple by any stretch.
You're going to need to register a hook, and you're going to have to build a callback procedure that gets called within another process's execution context -- this is not going to be .NET code (probably C instead), and will have to be in a DLL. That callback procedure will get called every time a certain class of events happens. It will examine the events it receives and filter out the ones you're interested, then send your application the notifications you want (probably via PostMessage). You'll then tap in to your application's main message loop to intercept those messages, and from there you can fire a .NET Event, or whatever you want.
Writing hook callbacks is tricky stuff because the code gets run within another process, not your own, and the memory management and concurrency issues take a bit of forethought. For that same reason, it's not going to be done in C#. Ideally, though, this callback code will be very small and very fast, since it's going to get called so often.
Also note that while perfectly "legal" in Win32, these system hooks have an immense amount of power and are commonly used by malware to change the way your system works. For that reason, you may run afoul of antivirus software if you attempt to do this sort of thing on a customer's computer.
Also note that the far-reaching effects of system hooks also means that simple programming mistakes can take down your whole system, which you will probably discover for yourself at some point while debugging; so save everything before you hit "run".
Good luck!
EDIT
Did a bit more search to see if there's any way to write the hook proc in C#, and came up with this:
How to set a Windows hook in Visual C# .NET
This is almost what you're looking for, but not quite. Hook procedures can either be global (which means that they run on every application) or thread (only runs within your application). The document states that:
Global hooks are not supported in the .NET Framework
Except for the
WH_KEYBOARD_LL low-level hook and the
WH_MOUSE_LL low-level hook, you cannot
implement global hooks in the
Microsoft .NET Framework. To install a
global hook, a hook must have a native
DLL export to inject itself in another
process that requires a valid,
consistent function to call into. This
behavior requires a DLL export. The
.NET Framework does not support DLL
exports. Managed code has no concept
of a consistent value for a function
pointer because these function
pointers are proxies that are built
dynamically.
Which means, again, to monitor things that go on outside your application's view, you need to set a global hook, which can't be written in .NET.
I have exactly the same issue as this, and I think I have a workable solution. Initially I looked into a similar option to the one mentioned by 'tylerl'. In my case however, instead of using 'SetWindowsHookEx', I attempted to use the similar function 'RegisterShellHookWindows'.
Unfortunately, this only succeeded in providing me with notifications of when a subset of windows are created/destroyed. The only windows which it provided notifications for are those shown on the taskbar.
Since I didn't fancy hacking into other processes, or writing the native code which would be required for SetWindowHookEx, I tried digging into the .NET automation APIs introduced in .NET 4.0, and I think this has the answer to your problem (at least as far as detecting when windows are opened / closed).
Here's a code snippet for using this API to detect windows being opened/closed:
using System.Windows.Automation;
private void StartMonitoringForWindowEvents()
{
Task.Factory.StartNew(() =>
{
AutomationEventHandler windowOpenedHandler = new AutomationEventHandler(OnWindowOpened);
System.Windows.Automation.Automation.AddAutomationEventHandler(
WindowPattern.WindowOpenedEvent, AutomationElement.RootElement,
TreeScope.Descendants, windowOpenedHandler);
});
}
private void OnWindowOpened(object source, AutomationEventArgs eventArgs)
{
try
{
AutomationElement sourceElement = (AutomationElement)source;
string message = string.Format(
"Automation.WindowOpened PID: {0}, Handle: {1}, Name:{2}",
sourceElement.Current.ProcessId,
sourceElement.Current.NativeWindowHandle,
sourceElement.Current.Name);
Debug.WriteLine(message);
// for each created window, register to watch for it being closed
RegisterForClosedWindowEvent(sourceElement);
}
catch
{
}
}
private void RegisterForClosedWindowEvent(AutomationElement element)
{
try
{
string elementName = element.Current.Name;
int processId = element.Current.ProcessId;
int nativeHandle = element.Current.NativeWindowHandle;
AutomationEventHandler windowClosedHandler = new AutomationEventHandler(
(ignoreSource, ignoreArgs) => OnWindowClosed(nativeHandle, processId, elementName));
System.Windows.Automation.Automation.AddAutomationEventHandler(
WindowPattern.WindowClosedEvent, element,
TreeScope.Element, windowClosedHandler);
}
catch
{
}
}
private void OnWindowClosed(int nativeHandle, int processId, string elementName)
{
string message = string.Format(
"Automation.WindowClosed PID: {0}, Handle: {1}, Name:{2}",
processId,
nativeHandle,
elementName);
Debug.WriteLine(message);
}
You will need to add a reference to the assemblies 'UIAutomationClient' and 'UIAutomationClientTypes'.
Here's a link to the MSDN documentation (you'll probably particularly want to take a look at the information on events):
http://msdn.microsoft.com/en-us/library/ms747327.aspx
Important implementation Notes:
1.) Notice that in the sample, I used a task factory to register for reception of the automation events. It's particularly important to avoid using the UI thread when registering for automation events or generally interacting with the automation APIs. Doing so can (and usually quickly does) result in a deadlock. Therefore, I use the task factory to ensure registration is done via the thread pool.
This also means, that the events will be received on the thread pool... So, if you need to perform any UI updates, you will have to marshal these across to the UI thread.
2.) You'll also note, that I capture any needed information on the element which may be closed, at the time of registration (using a closure). This is because, once the element is closed, we will no longer have access to this information - since the element has been destroyed.
Phil
The answer is not C# (or .Net) specific. You'll need to call SetWindowsHookEx( WH_CBT, ... ). This will allows to know when a window is created, destroyed, moved, sized, etc. You'll also need to get the relevant information from the window to identify if its one you need to do something about. Perhaps GetClassInfo, GetWindowLong, and GetWindowText.
The problem with the SetWindowsHookEx is that in order to get events from every window you need to have a separate win32 dll with the function in question exported. Although you might have success with the procedure outlined here.
To expand upon Joel Lucsy's answer, you need to use the Win32 API. However, there's a nice library, the Managed Windows API, that provides an object-oriented wrapper over common APIs. It may have what you need.