I would like to ask, can I inspect calls made to dlls inside an MFC based app ?
Can I have a history of calls with method names& arguments values ??
Is there a tool than generates such a report ?
Thanks,
hopeweise
from http://msdn.microsoft.com/en-us/library/dd264944.aspx#BKMK_CallsAndParameters
When you enable IntelliTrace Events and Call Information, IntelliTrace collects a record of each call entry and exit. On entry, IntelliTrace collects name and value information for each parameter.
Related
I managed to send Toast messages but once clicked, the callback is not invoked. This is the toast-tutorial that was used.
The messages should be sent through classic Win32 and in order to do this, a shortcut needs to be created which contains the AUMID and the CLSID. This is explained in Step 5 of the tutorial, where for MSIX and WiX these id's are put in their config files. There isn't an explanation how to generate the shortcut in Win32, but can be found in another aumid-tutorial.
After following the steps provided, sending the toast works fine, but clicking it does not invoke the callback for handling the feedback.
One thing that stands out, is that the installShortcut function uses only the AUMID in the creation of the shortcut, the CLSID is only used when registering the COM Server, where the configuration for MSIX and WIX shortcuts use both.
It seems as there is the link missing that windows needs to route the feedback back into the app.
Toasts use the "ToastGeneric" binding.
Any idea why this is happening?
Just on the name alone it seems to me like you need to set the PKEY_AppUserModel_ToastActivatorCLSID property on the .lnk and not just the AUMID.
MSDN says:
Used to CoCreate an INotificationActivationCallback interface to notify about toast activations.
This page is marked as pre-release but does have a different InstallShortcut function that sets this property.
I have run the desktop-toasts sample successfully. As the code comment comments,
For the app to be activated from Action Center, it needs to provide a
COM server to be called when the notification is activated. The CLSID
of the object needs to be registered with the OS via its shortcut so
that it knows who to call later. The WiX installer adds that to the
shortcut. Be sure to install the app via the WiX installer once before
debugging!
If running the package project directly, It also works. The following picture shows What happens when I installed DesktopToastsCppWrlApp.msi generated by Wix Toolset.
I understand there are functions that can easily write windows registry, however I found out that in new MFC project created with wizard, some information (like split bar position, visibility of controls) gets stored automatically (or at least I found no CWinApp::Write* calls in the project). Since I have also older projects that don't have this behaviour I need to figure out how to make this without help of project wizard. Would anyone please know how does this work?
The MFC control state saving magic happens in the 'New' MFC Feature Pack, specifically in the SaveState methods, for example CMFCToolBar::SaveState.
To take advantage of this you'll therefore need to upgrade your Toolbars and Menus to use the newer controls and upgrade your application to inherit from CWinAppEx. I recommend that you use a New MFC Wizard based app as a guide on how to upgrade your old MFC app.
Most of the information is saved in CPane::SaveState(), thus if you want state of some component saved, you need to use classes derived from CPane. (for more info here is the class hierarchy).
The process of saving window states is initiated through CFrameImpl::OnClosingMainFrame(). This function in turn calls CWinAppEx::SaveState() which saves some application settings and then ALL instances of CMFCToolBar (they add themselves to global list of CMFCToolBars in call to OnCreate). In a similar way all dockable panes are saved but the list belongs to your main frame. Then positioin and size of your main frame is saved.
CViews and CFrameWnds are somewhat less favored, for what I found and tried out, the only information saved was visibility.
I used that loooong time ago. If I correctly reminds it, you should save the informations you want in a overridden CWinApp::ExitInstance() before calling base class method, and you load them in CWinApp::InitInstance. Be sure to allow for default values, because at first run, there will be nothing to load, and do not forget to call (or copy) base class.
I have defined a LocatorBuilder function and inserted it as the first element of LocatorBuilders array. It is working nicely. However, when I add an alert() at the top of my function, I observe that my function is being called twice for each user click that is recorded. Specifically, when I turn on recording and click a button on the page, the sequence of events is: 1) my function gets called, 2) the click is recorded utilizing the locator expression that I have produced, 3) the browser processes the click, 4) my function is called again.
Note - I can't find this documented anywhere, but I surmise that fundamentally, the recorder calls each function in the LocatorBuilders list, each returning a candidate locator expression, until it gets a non-null expression that matches exactly one element on the page.
So my function works as desired, but the extra function call seem redundant. Is there some valid reason that my expression builder function needs to be called more than once? For example, is it possible for the subject HTML element to change between calls? What is the recorder doing between successive calls to my function?
EDIT: DOH! I discovered that I was adding my function into the LocatorBuilders.order list twice. So now my function only gets called twice. Still though, why multiple calls?
When you define a locator-builder via LocatorBuilders.add(name, func), Selenium adds the name to the global array: LocatorBuilders.order. The recorder iterates over these names on each user event, calling each builder function in turn.
Custom definition(s) are loaded into the IDE by configuring your script as either a "Core extension" or an "IDE extension". Both sets of extensions are loaded when the Selenium IDE window opens, (IDE then Core), so it might not seem to matter which one you specify. But beware that the Core extension scripts get reloaded the first time a command is played back in the IDE window. Therefore scripts that are configured as Core extensions need to be idempotent.
So since a locator-builder is Recorder functionality, configure it as an IDE extension and it will get loaded only once. If there is some reason it needs to coexist with runtime code, (shared logic is likely), you can load it as a Core extension, but make sure it is idempotent. (And it may as well be loaded only in the IDE.) For example:
if ("SeleniumIDE" in window) { // we're running in the IDE window
var i = LocatorBuilders.order.indexOf(locatorName);
if (i != -1)
LocatorBuilders.order.splice(i, 1); // remove a previous entry
LocatorBuilders.add(locatorName, function(elem) { ...
}
(Note that the indexOf() and splice() array methods are not supported by all browsers, but Firefox does, and this is IDE logic.)
I have a third party encryption library, which may create a MessageBox if key creation fails. The failure can be caused by bad random number generation or other rarities, and in most cases, trying again will result in success. My code will attempt key creation up to three times before deciding it failed.
Now, the issue is that the program may be used with automation. If a MessageBox is created during automation, it will block the process forever, because there's nobody to click the 'OK' button.
Does anyone know of a way to catch when this message box is created and automatically close it?
Anything is fair game, as long as it's not something that will make security suites angry. This means no hooking or code tunneling.
In summary, I need to catch when a MessageBox is created and close it. The MessageBox's creation is outside of my control. Modifying the code at runtime is not acceptable.
Also, I've noticed there are some other similar questions, but they don't have the same requirements.
EDIT: Additional note, I can find the message box via searching through all windows until I find one with a matching title and then send it a WM_CLOSE message, but I don't think this is a great solution. I also have no guarantee that the message box has been/will be displayed, or how long after my call it will be displayed. It could display instantly, it could display 1200 ms later, or it could not display at all.
Just before you begin the encryption process, install a WH_CBT hook, and in its callback watch for an nCode of HCBT_CREATEWND. If you get a matching class name ('#32770 (Dialog)' ?) and a matching title either return a nonzero value from the callback, or if that doesn't work post a WM_CLOSE (or a BM_CLICK to a relevant button if selecting an option is necessary). Uninstall the hook after the process for not messing with every possible dialog your application pops up.
That sounds like bad design on the part of that library. Generally any sort of utility library (like encryption) has no business invoking any kind of GUI (unless you explicitly ask it to).
Is there possibly some configuration or setting in this library that could disable its use of message boxes?
If not, I'd suggest that you might want to investigate using a different library. After all, if the designers of this library have already made this kind of poor design decision once, then there may be other unfortunate surprises lurking in there.
You can hope that it will be found by GetForegroundWindow, but this may catch other applications. The more brute force way is to iterate over all windows with EnumWindows looking for something that has a caption or text equal to this shown by the library.
I have once "remote controlled" an application by sending mouse click events to some controls. I guess you would have to do this in a separate thread that is watching for Events if a window is opened. Pretty ugly but working...
Create a new thread. If your function fails and a Message Box is opened, obtain a handle to the message box by looping through the windows (GetTopWindow, GetNextWindow) and comparing the window's process id to the one returned from GetCurrentProcessId().
Or, you can avoid all the hard work and just hook the MessageBox API with detours. It's not very hard, and if you don't want to pay for detours, you can do it manually.
Call VirtualProtect and set the memory protection at MessageBox at PAGE_EXECUTE_READWRITE
Create a naked function, and use it as a trampoline.
Create a function identical in parameters to MessageBox (this will be your hook)
Create a jump from MessageBox to your hook function.
I have a carbon C++ application and I would like to programmatically do the equivalent of Command-H (to hide the application) which is available in the Application menu for my app. I have explored the carbon API for TransitionWindow and HideWindow and while these can hide my window, they do not do the equivalent of Command-H. I looked into the AppleEvent reference on the offhand I needed to create an AppleEvent but I didn't see one for hide application. Any thoughts?
Sorry to answer my own question but the ShowHideProcess() API seems to do what I want. If there are better solutions I would love to hear them.
Just a note: hiding a Window is very different to hiding an Application.
You can also send a kHICommandHide ('hide') command event from the Carbon Event Manager (which is what that menu item does, and which calls ShowHideProcess() when processed) if you prefer, for instance if you'd like this action to be materialised by an event.
I looked into the AppleEvent reference on the offhand I needed to create an AppleEvent but I didn't see one for hide application. Any thoughts?
I'm no expert but you can just use AppleEvent to set the visible property of a process to false – at least it works with an AppleScript
tell application "System Events"
set visible of process "xyz" to false
end tell
On the other hand, your API seems to be the most direct way and the above code probably just uses it as well.