|
|
Just looking for a little clarification here. We have a third party application that we don't control the codebase to, however we do provide the calculation engines it uses. What I am looking to do is time how long it takes from when someone clicks a button within their application to when the report it creates is subsequently displayed. I thought we could use a Windows Hook but from the bit I have read about them, it requires you to have a handle to the process loaded in memory, with the examples I have seen they typically have control over this simply by calling LoadLibrary() . I don't want to load another instance of the executable into memory to get a HANDLE to it. Does anyone have any comments to point me in the right direction? Thanks in advance.
- Nick Parker My Blog | My Articles
|
|
|
|
|
>> however we do provide the calculation engines it uses.
So it's a DLL? If so you can change your DLL to get the handle to the current process. Your in.
If they link to your lib staticaly that won't work of course. However you can enject DLL into a process. There are articles on MSDN and maybe even here at CP about doing that.
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Depending on what all things the calculation engine does, a timer approach might be useful. If the calculation engine doesn't format the end report, then consider creating a timer that calculates the elapsed time, and one timer that polls for the existence of the report window.
I know the latter approach is more or less a hack, but being unable to access the actual codebase it becomes quite difficult to measure the time it takes for a code fragment to execute. So, I would go with one or two timers, if I needed the functionality you describe.
Additionally, if you need to determine when the button is pressed, it becomes even more difficult. The only option would be to monitor the messages posted to the program window, and capturing the WM_COMMAND message send by the button click to start the timer.
All in all, the whole idea sounds like a waste of time and resources. Why not ask the developer of the third party app to implement a timer ?
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
If the 3rd party app is not a multithread app, you should be fairly safe with using a combination of FindWindow() for the HWND and GetWindowThreadProcessId() for the process identifier when you have the HWND and lastly OpenProcess() to get its HANDLE once you have the process identifier.
And there's EnumProcesses() , but that's NT only.
Jeremy Falcon
|
|
|
|
|
Hi,
I am interested in understanding how in VC++6 to program a toolbar for Internet Explorer. Is it simply an MFC app or what? Obviously, I'd have to have it work with IE somehow, can anyone point me in the right direction?
|
|
|
|
|
Internet Explorer, in it's later versions, is tightly integrated with the Windows Shell. The toolbars you refer to are actually COM objects, which implement a set of certain interfaces. The big idea behind this is that you can use the same objects for both Explorer (Shell) and IE.
To see this feature in action, open IE. You probably have some type of an extra toolbar like CodeProject SearchBar or Google Toolbar. If you open up 'My Computer', you can use 'View'->'Toolbars' to enable to Google Toolbar for Windows Explorer as well. The difference is that Internet Explorer has a specific set of options, which 'differentiate' it from standard Explorer.
To sum it all up, in order to create an IE toolbar, you need to create a COM object that supports the specific interfaces. Then register this object with OLE, and restart IE. It will query OLE for a list of registered objects and allows the user to hide/show these toolbar objects through the View->Toolbars/Explorer bars menu options.
For an MSDN link, containing in-depth discussion and a set of code examples, go here
Also, a CodeProject IE Programming area is available in here.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
I'm trying to make a dialog that fits on screen resolutions 800*600 and up. My resolution is 1600*1200.
When I was originally designing my dialogs I foolishly assumed that the number Visual Studio gives in the lower right hand corner is the size of the dialog in pixels, so I designed it to be less than 700. Lo and behold, it's way too big for an 800*600 resolution. How the heck do I know what numbers to keep the size under?
Thanks,
Jay
|
|
|
|
|
Dialogs are measured in DLUs, dialog units. The size of a dialog unit is dependent on the size of the system font. The idea is that dialogs should keep their relative size no matter what system font is used.
The easiest way to make sure a dialog fits at the minimum supported resolution is simple - switch your graphics card to this resolution, draw a dialog box, then use this dialog box as a maximum-size template for all the other boxes.
You can find info on DLUs on MSDN, search for GetDialogBaseUnits .
|
|
|
|
|
I have a simple dialog based app that uses an embedded web browser control. The site that I browse to is password protected - after getting the username and pwd from the user, I embed them in the url that the web browser control navigates to, eg: http://user:pwd@restOfUrl.com .
Everything works fine if the username and pwd are valid.
If the username and pwd are not valid, the browser control displays the standard IE username/pwd dialog. Is there any way to recognize this situation and display my own dialog/messageBox? Basically what I was hoping to do is trap the error in OnNavigateErrorExplorer() , cancel the navigation, and retry after displaying an app-specific error dialog.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Ravi Bhavnani wrote:
Basically what I was hoping to do is trap the error in OnNavigateErrorExplorer(),
OK, I was able to trap the error in OnNavigateErrorExplorer() (and take over from there), but I'm unable to suppress IE's login dialog that's displayed before OnNavigateErrorExplorer() is called.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
SetSilent (TRUE); prevents the dialog from being shown. All is well!
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Hi,
I have a very strange problem with JIT (just-in-time) debugging under WinXP. I have been using Visual Studio 6.0 and recently I installed WinXP instead of Win2K. My problem is that now JIT debugger doesn't work. When my application breaks down and I click "retry" + "debug" then nothing happens, debugger is not loaded. This is a big problem and I spent several hours by trying to fix this problem. We have two computers in our office (same WinXP, same VS) and this problem appears on both PCs. Does anybody has similar experience?
Remarks:
1/ When I start debugger from VS then it works normally.
2/ After installation of VS6 under WinXP I got a message that there could be problems with debugger and it was recommended to run VS tools -> Windows NT symbol setup. When I was trying to do this then during installation I got many messages that *.dbg files are incompatible with system dlls (so I canceled the installation).
3/ I installed VS service pack 6 (no change) and WinXP SP1 (no change)
Thanks Mirek
|
|
|
|
|
check the following registry entry
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\AeDebug\Debugger
it should be something like.....
"C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\msdev.exe" -p %ld -e %ld
|
|
|
|
|
Thanks for advice, unfortunately this is not the reason of my problems. I had already checked this registry key before I sent my question to this forum. I know that installation of VS .NET changes settings for default debugger and I also had a suspicion that this could be the problem. But I have not installed VS .NET on my computer, the key is exactly as you wrote ("C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\msdev.exe" -p %ld -e %ld) and debugger still doesn't start in the JIT mode.
Mirek
|
|
|
|
|
I have a MFC project and a Visual FoxPro Database. A creat te connection using ODBC, but when i execute the program it takes up to 20-30 seconds before running. Can anyone tell me what could be the problem? Thanks!
|
|
|
|
|
Hi I can't seem to get a simple BITMAPFILEHEADER working.. all I'm trying to do is:
BITMAPFILEHEADER blah;
and VC says BITMAPFILEHEADER is unrecognized, and then another file saying I can't overload BITMAPFILEHEADER.. I included WinGDI.h and windows.h, not sure what else to do..
|
|
|
|
|
What is the value of _WIN32_WINNT and WINVER ?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
This works:
#include <windows.h>
BITMAPFILEHEADER blah;
int APIENTRY WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow)
{
return 0;
}
Your problem lies not with the BITMAPFILEHEADER declaration, but somewhere else.
|
|
|
|
|
I haven't tried that exact code but basically what I'm doing is just loading VS.NET and starting a C++ Windows Form project and just double clicking on the form to get to the "Form1_Load" event and just inserting that single line of code "BITMAPFILEHEADER blah;". It doesn't seem to work for me.. Here's exactly what it says:
error C2065: 'BITMAPFILEHEADER' : undeclared identifier
error C2146: syntax error : missing ';' before identifier 'blah'
error C2065: 'blah': undeclared identifier
error C2378: 'BITMAPFILEHEADER' : redefinition: symbol cannot be overloaded with a typedef
|
|
|
|
|
My knowledge of Windows Form projects is nil, null and void. But you will want to concentrate on the first error - the following ones are most likely fixed by fixing the first. What is the first one really saying? That the definition of BITMAPFILEHEADER was not found. You have correctly identified that this is included in wingdi.h. This header is included from windows.h. What you will want to do is:
1. Make sure that you have included windows.h at the correct place of the code.
2. Make sure that wingdi.h is included from windows.h. You do this by opening windows.h and check if there is any condition attached to the include.
3. Make sure that BITMAPFILEHEADER is defined in wingdi.h. You do this by opening wingdi.h, making sure that there are no unfullfilled conditions before it is defined.
If everything looks ok, that is, all necessary #defines exist, the files are included as expected etc. you then make sure that there are no other prerequisites (such as naming conflicts due to the Windows Form-project type). This you do by checking the documentation on specifics on Form-projects - you might find that you have to do something specific to use API-stuff in this case. You might want to try to simplify the code to the minimum possible, much as I did with a Win32 project when experimenting.
|
|
|
|
|
hi,
i got an MDI app with Doc/View Architecture.
im one of my View window i want to pop an Dialogbox with editboxes and buttons.
whats the problem?
the problem that this dialogbox can get out of my MDI mainframe...
how can i keep it inside the mainframe?
is there any way or i need to make it Doc/View too?
Avi.
|
|
|
|
|
This is normal behaviour for a dialog box. I suggest that you keep it that way, as one of the ideas with a user interface is having all applications working more or less the same way.
|
|
|
|
|
I tried creating a child dialog that shared the DC with it's parent: no luck. MFC just doesn't support this behaviour.
Best approach would be to derive your own CMDIChildWnd, which uses a CFormView instead of a CView. The MDI child window worries about the fact that the window can't leave the parent's zone, and the CFormView can be used to display standard dialog controls from a dialog template resource.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
One way would be to override the dialog's OnMoving() method, like:
BOOL CMyDlg::OnInitDialog()
{
CDialog::OnInitDialog();
GetWindowRect(m_rectOrig);
return TRUE;
}
void CMyDlg::OnMoving(UINT fwSide, LPRECT pRect)
{
CRect rect;
((CFrameWnd *) AfxGetMainWnd())->GetActiveView()->GetWindowRect(rect);
GetParent()->GetWindowRect(rect);
pRect->left = max(rect.left, pRect->left);
pRect->left = min(pRect->left, rect.right - m_rectOrig.Width());
pRect->right = pRect->left + m_rectOrig.Width();
pRect->top = max(rect.top, pRect->top);
pRect->top = min(pRect->top, rect.bottom - m_rectOrig.Height());
pRect->bottom = pRect->top + m_rectOrig.Height();
}
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|