|
Yes...which is exactly why I'm asking what happened... 
|
|
|
|
|
5 .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Megidolaon wrote: What happened?
Does this help?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
I need to write a simple software to do something very repetitive...the perfect job for a program (not for humans)!
This software has simply to do many (many many many) times:
1) press a button on another application (no source code available, only the exe is provided) [ x and y coordinates of the point to click are known]
2) catch an area of the screen to save it as an image [the rect to catch is known]
About point 2 I found, here on codeproject, some examples on how do the catch of the screen and the file export. But I've absolutely any idea about point 1). This because it is something completely different from the usual software I develope.
Can you point me in the right direction? any suggestion?
thanks!!
Russell
|
|
|
|
|
How about sending a BM_CLICK message to that other window?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Nice suggestion, thanks.
Never done anything like this before, so I started with something easy...but after many test this code it is not seems to work.
After that the timer is started I have some seconds to activate the notepad window...but nothing is written there...do you see any error in the way I'm using sendmessage?
void CClickAndCaptureDlg::OnTimer(UINT_PTR nIDEvent)
{
if(nIDEvent==ID_TIMER){
{
TRACE("Timer arrived\n");
KillTimer(m_Timer);
}
CWnd* pWnd=GetForegroundWindow();
if(!pWnd) return;
{
TRACE("Sending messages\n");
pWnd->SendMessage(WM_CHAR,'H',0);
pWnd->SendMessage(WM_CHAR,'E',0);
pWnd->SendMessage(WM_CHAR,'L',0);
pWnd->SendMessage(WM_CHAR,'L',0);
pWnd->SendMessage(WM_CHAR,'O',0);
pWnd->SendMessage(WM_KEYDOWN,VK_RETURN,0);
}
}
CDialog::OnTimer(nIDEvent);
}
Russell
|
|
|
|
|
Ok, found the way to use notepad: needed Spy++.
There was the bloblem to find the correct HWND, together to the problem to send the rigth messages.
this code to send a simple 'w'
HWND hc=::FindWindow(CString("Notepad"), NULL);
hc=::GetWindow(hc, GW_CHILD);
::SendMessage(hc,WM_KEYDOWN,0x57,0x110001);
::SendMessage(hc,WM_CHAR,0x77,0x110001);
::SendMessage(hc,WM_KEYUP,0x57,0x110001);
Thank you again
Russell
|
|
|
|
|
Is there a way to separate the buttons on a spin control? I would like to place them in a horizontal orientation and place the buttons on either side of the text block that displays the value being adjusted.
Thanks
|
|
|
|
|
You can orient the spin control either vertically or horizontally, but separating the buttons is not possible.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Hello,
I am writing an activex and the activex is about preview the vidoe. So the inside of .ocx code is basically to call the filters to build the filter graph.
But I meet a strange problem now. I use Dependency Walker to find which dll I will redistribute.
The .ocx file need msvcr80.dll and mfc80.dll. The one filter (Ex : a.ax) which is used in the filter graph needs msvcr80.dll.
And I packed all filters which I need into a .cab file and test it on virtual pc first. (The virual pc doesn't install visual studio 2005)
After I unpack the .cab file and install the vcredist.exe(2005sp1).
Then I drag .ocx file into the dependency walker, there are two yellow question mark on the msvcr80.dll and mfc80.dll. So my .ocx file can't be installed.
But if I drag a.ax into the dependecy walker, the msvcr80.dll can be found...
I don't know why it happen. I checked the module search order, two files all use "Side-by-Side components" first. But one can find the msvcr80.dll, the other can't.
Even if I copy the msvcr80.dll and mfc80.dll into the directory which .ocx file exists. Two yellow question mark disappers but I still can't register it.
The error is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"
I also check the manifest file of .ocx (ProgramNameActiveX.ocx.intermediate.manifest), but it contains three dependency item.
The three items are(name='Microsoft.VC80.CRT', name='Microsoft.VC80.MFC', name='Microsoft.VC80.DebugCRT')
Why ? I am very sure that I use the release mode to build the .ocx. Why VC80.DebugCRT appear ? Is this may be the fail reason ?
I don't know how to solve this strange problem. I tried find some data on the internet and tried some methods, such as
put the Microsoft.VC80.CRT.manifest and Microsoft.VC80.MFC.manifest together with the .ocx file.
Or put the ProgramNameActiveX.ocx.intermediate.manifest together with the .ocx file.
But all are failed...
I also thought it might be the project setting. But I don't know how to modify the project setting.
Now the activex can be installed only on the machines which is installed visual stuido 2005.
But my goal is to let it can be installed on the machine without visual studio 2005.
Does anyone may have the suggestion to help me to solve this problem ?
My environment of development : visual studio 2005 sp1 + ms platform sdk 2003 sp1
environment of virtual pc : xp sp3
Thanks a lot.
|
|
|
|
|
My problem is solved now.
It might be the reason of wrong manifest file.
I solved this problem by commenting on the lstrcpyn() function. This function is used for querying the filter name.
After this step, the ProgramNameActiveX.ocx.intermediate.manifest contains two dependency item (Microsoft.VC80.CRT and Microsoft.VC80.MFC)
And the .cab can be installed correctly.
If I don't comment on this function, there will be a warning message.
msvcrt.lib(cinitexe.obj) : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
Then the ProgramNameActiveX.ocx.intermediate.manifest contains three dependency item. (Microsoft.VC80.CRT, Microsoft.VC80.MFC and Microsoft.VC80.DebugCRT)
Then the .cab can't be installed correctly and the.ocx can't be registered by hand.
But I still don't know why comment on this code can let the program work.
The sample "AudioCap" in platform sdk use this function too.
I also checked the project setting about Runtime Library. My project is the same as the sample "Audio Cap".
But the sample can work without adding the comment.
|
|
|
|
|
I have an MFC, multi-document template application, built using Visual Studio 6, which has been working for a long time now. Recently I moved to a new development machine and now my application hangs whenever I click the File menu and choose Open.
I have run it in debug mode and traced into the MFC code. The point of failure is in DlgFile.cpp(part of Microsoft's MFC source) at line 108 where it calls ::GetOpenFileName(&m_ofn). It goes in there never to return.
I spotted that the m_ofn structure points at a hook function _AfxCommDlgProc so I set a break point in that. The dialog receives the following windows messages before the application hangs: WM_SETFONT, WM_INITDLG, WM_SHOWWINDOW, WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, WM_CHILDACTIVATE, WM_WINDOWPOSCHANGED then WM_SIZE. The WM_SIZE message is processed OK and AfxCommDlgProc then exits back to code for which source is unavailable. My dialog never receives another message.
As a control I then tried exactly the same experiment on another MFC application of mine - one which doesn't fail. It acts exactly the same except that the WM_SIZE message is followed (after a short but noticable delay) by a WM_SETREDRAW after which the Open File dialog box appears.
If I let the failing application hang then click on Debug, Break, the call stack is singularly uninformative:
NTDLL! 7c90eb94()
USER32! 7e4195f9()
USER32! 7e4196a8()
BROWSEUI! 75f8afc9()
BROWSEUI! 75f8b591()
SHLWAPI! 77f69588()
NTDLL! 7c927545()
NTDLL! 7c927583()
NTDLL! 7c927645()
NTDLL! 7c92761c()
KERNEL32! 7c80b683()
I am at my wits end. I am using the standard MFC file open mechanism with no undue cleverness. I can see no tangible difference between the failing application and a different application which works, apart from the file types it's looking for. Has anyone any sensible suggestions what to try next?
Keith
|
|
|
|
|
Does it timeout and eventually show or hang forever?
Is it waiting for a reply from a network drive?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Does it timeout and eventually show or hang forever?
Is it waiting for a reply from a network drive?
So far as I know it hangs forever - but forever is a long time I may just not have stuck around long enough.
I don't think it's a network drive issue because I have two similar applications. One always hangs and the other always works. There is clearly a tangible difference between the two but I can't figure out what it is.
Keith
|
|
|
|
|
Does this code ripped right from the docs fail as well?
TCHAR szFilters[]= _T("MyType Files (*.my)|*.my|All Files (*.*)|*.*||");
CFileDialog fileDlg(TRUE, _T("my"), _T("*.my"),
OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, szFilters);
if(fileDlg.DoModal() == IDOK)
{
}
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark
I was wrong. It doesn't hang forever. I decided to leave it whilst running a stop watch. After clicking File, Open there is (on my laptop) a 1 minute and 50 seconds delay before the standard open dialog appears. This is solidly repeatable. If I cancel the open-file dialog and then click File Open again then there is another 1:50 delay until the open-file dialog reappears.
I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay.
Keith
|
|
|
|
|
Keith (MapMan) wrote: The identical code, pasted into another application, works without any delay.
That's not good
I'm thinking...
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
>>I'm thinking...
I'm giving up for today so no rush. One more bit of information. File Save As exhibits same long delay before displaying dialog.
Keith
|
|
|
|
|
Mark
>>I'm thinking...
If you are still thinking, stop. What my computer needed (apparently) was a good night's sleep. This morning I cannot reproduce the problem. The application works perfectly! Contrary or what? I've not even rebooted in the interim. At the end of the day I just shut the lid on my laptop and it hibernates.
I fired it up briefly at home yesterday evening to check my emails (didn't even try to run the failing app) then this morning I started again, connected to the same office network environment as yesterday, and the problem has magically gone away.
I guess we shall just have to put it down to one of those strange abberations that computers seem to have from time to time. If anyone has any theories I'd be interested to hear them but I suspect they will have to remain just that, theories.
Keith
|
|
|
|
|
Crazy
Thanks for the update!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Keith (MapMan) wrote: I pasted in your code snippet and that also takes nearly 2 minutes before the dialog appears so it's not the filters which are the problem. The identical code, pasted into another application, works without any delay.
That makes it sounds as though CFileDialog may not be the problem. How about just creating a dummy MDI application to see what it does with all of the default settings and code?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
I think you're probably right that it's not CFileDialog's problem as such. Something else about the application is causing the problem.
I'm pretty confident that if I created another dummy MDI app it would not exhibit the problem because I already have other real, not dummy, MDI apps which don't exhibit this behaviour.
What I think I might do is take a copy of the failing application and start knocking bits out of it to see if I can find something which makes it work. If I don't get anywhere that way then I may try as you suggest, start with a brand new project then gradually add back in the functionality of my app. It's going to be a long haul, though. There's rather a lot of it.
Keith
|
|
|
|
|
I had a similar problem in which the standard MFC application was crashing on certain action inside file open dialog on few machines with a simple code.....
The problem for me was solved for me after downloading a windows hotfix
refer to this link if you can find something http://www.bokebb.com/dev/english/1960/posts/196055272.shtml[^]
|
|
|
|
|
Wow, great link, I've had this problem for a good while on one particular machine, kind of forgot about until now.
|
|
|
|
|
Thanks for the suggestion. I did follow up the link you posted but I think that situation is different. It was a crash, rather than a hang, and it occurred after the open-file dialog box was displayed. In my case the dialog is never displayed. It hangs before it gets to that point.
Keith
|
|
|
|