|
BobInNJ wrote: Any advice?
Does the program fail to start, or does it start and then stop before any window is drawn? How about setting a breakpoint in the app's InitInstance() to find out?
"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
|
|
|
|
|
BobInNJ wrote: I would like to get this example running, however, I am finding it hard to debug.
Maybe we could help with that, however you should be more detailed about the runtime error.
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]
|
|
|
|
|
Thanks for the responses. Here are the details on the error: It dies with an assertion
error in the following MFC module:
void CSingleDocTemplate::SetDefaultTitle(CDocument* pDocument)
{
CString strDocName;
if (!GetDocString(strDocName, CDocTemplate::docName) ||
strDocName.IsEmpty())
{
// use generic 'untitled'
ENSURE(strDocName.LoadString(AFX_IDS_UNTITLED));
}
pDocument->SetTitle(strDocName);
}
Here is my InitInstance method.
BOOL CPaintApp::InitInstance ()
{
SetRegistryKey (TEXT("Programming Windows 95 with MFC"));
LoadStdProfileSettings ();
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate (
IDR_MAINFRAME,
RUNTIME_CLASS (CPaintDoc),
RUNTIME_CLASS (CMainFrame),
RUNTIME_CLASS (CPaintView)
);
AddDocTemplate (pDocTemplate);
RegisterShellFileTypes (TRUE);
CCommandLineInfo cmdInfo;
ParseCommandLine (cmdInfo);
if (!ProcessShellCommand (cmdInfo))
return FALSE;
m_pMainWnd->DragAcceptFiles ();
return TRUE;
}
The code reaches the call to ProcessShellCommand. However, it dies in that call. Here is the call stack when it dies.
> chap8.1.exe!CSingleDocTemplate::SetDefaultTitle(CDocument * pDocument=0x003d9610) Line 210 + 0x2b bytes C++
chap8.1.exe!CSingleDocTemplate::OpenDocumentFile(const wchar_t * lpszPathName=0x00000000, int bMakeVisible=1) Line 141 C++
chap8.1.exe!CDocManager::OnFileNew() Line 848 C++
chap8.1.exe!CWinApp::OnFileNew() Line 22 C++
chap8.1.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget=0x0065eaf8, unsigned int nID=57600, int nCode=0, void (void)* pfn=0x004afaee, void * pExtra=0x00000000, unsigned int nSig=57, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 82 C++
chap8.1.exe!CCmdTarget::OnCmdMsg(unsigned int nID=57600, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 381 + 0x27 bytes C++
chap8.1.exe!CWinApp::ProcessShellCommand(CCommandLineInfo & rCmdInfo={...}) Line 24 + 0x20 bytes C++
chap8.1.exe!CPaintApp::InitInstance() Line 43 + 0xc bytes C++
chap8.1.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020928, int nCmdShow=1) Line 37 + 0xd bytes C++
chap8.1.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020928, int nCmdShow=1) Line 30 C++
chap8.1.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C
chap8.1.exe!wWinMainCRTStartup() Line 182 C
kernel32.dll!7c817067()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
The path of execution, includes the following method:
CPaintDoc::CPaintDoc ()
{
m_lineArray.SetSize (0, 64);
}
While the code is dying inside an MFC module, I have to assume that it is not a bug with MFC. Since, I am doing this as a learning exercise, what is the best way for me to debug this?
Thanks
Bob
|
|
|
|
|
I created an environment variable using the Windows System Properties page. In my program I called getenv("varname") to retrieve the value of my environment variable.
After changing the value of my variable, I can see the change when running my program from the desktop but I get the old value when running the program from within MS Vis C++ unless I restart Vis C++. Obviously Vis C++ reads the environment settings and uses them from that point on.
Is there any way to "refresh" the environment from within Vic C++ so that the next time I run my program, it picks up the new value?
Thanks!
jpyp
|
|
|
|
|
jpyp wrote: Is there any way to "refresh" the environment from within Vic C++ so that the next time I run my program, it picks up the new value?
I don't know if there's a way to do that in Visual Studio.
This[^] may at least explain why it happens.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Looks like the only way to get the new value is to read it from the registry. Using regedit I can see the new value under key
HKEY_CURRENT_USER\\Environment\\SSSRights
which has a value of "A".
But there seems to be something wrong with my code becomes I always get a return value of 87 which apparently means ERROR_INVALID_PARAMETER when I call RegQueryValueEx(). hMyKey has a valid handle after call to RegOpenKeyEx().
Here is my code:
HKEY hMyKey;
long lResult;
LPDWORD pKeyType = REG_SZ;
LPDWORD pKeySize = 0;
char* strKeyName = "SSSRights";
char* strKeyVal = "\0";
RegOpenKeyEx(HKEY_CURRENT_USER, "Environment", 0, KEY_QUERY_VALUE, &hMyKey);
lResult = RegQueryValueEx(hMyKey, strKeyName, NULL, pKeyType, (LPBYTE)strKeyVal, pKeySize);
RegCloseKey(hMyKey);
jpyp
|
|
|
|
|
You couldn't possibly compile that
Try
HKEY hMyKey;
if (ERROR_SUCCESS == ::RegOpenKeyEx(HKEY_CURRENT_USER, _T("Environment"), 0, KEY_QUERY_VALUE, &hMyKey))
{
DWORD KeyType;
DWORD KeySize = 0;
TCHAR strKeyName[] = _T("SSSRights");
if (ERROR_SUCCESS == ::RegQueryValueEx(hMyKey, strKeyName, NULL, &KeyType, NULL, &KeySize))
{
<code>
TCHAR *pKeyVal = new TCHAR[KeySize / sizeof (TCHAR)];
::RegQueryValueEx(hMyKey, strKeyName, NULL, &KeyType, (LPBYTE)pKeyVal, &KeySize);
delete[] pKeyVal;
}
::RegCloseKey(hMyKey);
}
Mark Salsbery
Microsoft MVP - Visual C++
modified on Thursday, October 16, 2008 3:51 PM
|
|
|
|
|
Yes it compiled without any errors/problems.
I tried yours and it works but it brings up the following questions:
Why do I need the first call to RegQueryValueEx? What does it do? Why does the first call fail when I provide a buffer instead of NULL?
Thanks!
jpyp
|
|
|
|
|
What compiler are you using?
This line alone won't compile:
LPDWORD pKeyType = REG_SZ; <-- error C2440: 'initializing' : cannot convert from 'int' to 'LPDWORD'
There's several problems
HKEY hMyKey;
long lResult;
LPDWORD pKeyType = REG_SZ; <code><-- wrong data type - should be a DWORD
It's also an OUT variable (if used correctly) so initializing it is pointless</code>
LPDWORD pKeySize = 0; <code><-- wrong data type</code>
char* strKeyName = "SSSRights";
char* strKeyVal = "\0"; <code><-- You need to actually allocate space for the returned characters
Had the query actually succeeded, it most likely would have crashed
trying to write data to a const character array of length 1.</code>
jpyp wrote: Why do I need the first call to RegQueryValueEx? What does it do?
It sets KeySize to the number of BYTES required to store the returned string.
I use that value to know how big the buffer needs to be, which I allocate on
the next line.
You could have just allocated an arbitrary number of bytes, but
you'd get a truncated string if the registry entry was longer than your buffer.
The function is capable of returning the necessary buffer size, so that's the
proper way to do it.
jpyp wrote: Why does the first call fail when I provide a buffer instead of NULL?
Your incorrect use of LPDWORD pKeySize = 0; effectively reults in passing a NULL pointer as the
lpcbData parameter in the RegQueryValueEx() call. That is not allowed - the function
needs to know how big of a buffer it has to return data in and also needs to be able
to set the actual number of bytes placed in the buffer.
Mark Salsbery
Microsoft MVP - Visual C++
modified on Thursday, October 16, 2008 4:35 PM
|
|
|
|
|
I use Studio 6.0 and you are right it does not compile. I had taken out the initialization before in my code but forgot to take it out in my first post here.
I understand now why it wasn't working initially. The size of the buffer must be the same as the value in the last field. I was providing a value of 0 for KeySize because I thought it was a output value only. So only one call is necessary but it is certainly safer to do it your way to get the actual size of the value.
As for the wrong data types, I took those directly from the MSDN library help page. Their data type are LPDWORD for the key type and key size fields.
Thanks a lot for your help!
jpyp
|
|
|
|
|
jpyp wrote: As for the wrong data types, I took those directly from the MSDN library help page. Their data type are LPDWORD for the key type and key size fields.
Are you talking about the parameter types for the RegQueryValueEx() function?
If so, then yes, that is the type of variable that needs to be passed...
that doesn't necessarily mean your variables are supposed to be that type.
For example, a parameter with type LPDWORD - if you read the docs for
that parameter, you'll see wording like "A pointer to a variable that receives..."
or "A pointer to a variable that specifies...". That is NOT what you were passing
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I just tried to use a map and since I don't know how to access an element yet, I thought I'd just set a breakpoint once it's filled and check the contents myself (I randomly assumed that like in VS C# you can see all members of an object at runtime if you set a breakpoint).
However, it doesn't even get there and I get a weird error instead:
Debugging Information for 'Graphics Test.exe' cannot be found or does not match. Symbols not loaded.<br />
<br />
Do you want to continue debugging?
What happened?
Thanks
|
|
|
|
|
Megidolaon wrote: What happened?
You reached what is sometimes referred to as "the limit of your knowledge". 
led mike
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
