|
I have a program which works on an open process. I need a way to spot if the process the program is working on has terminated. So I setup a CWorkerThread and use AddHandle() with the handle of the open process. When the handle becomes signaled, I send a message to the main window of my app.
So what's the problem?
When the process terminates and the Execute() method fires, I have to remove the process handle from the thread or it will keep firing messages to the main window. But when I use RemoveHandle(), the thread blocks on the Refresh() method.
Why this is happening? Any suggestions on how to fix it?
Thanks.
|
|
|
|
|
Hi,
I did that using MFC, just create a Worker thread and the process and waitforsingle/multiple objects, I can try to find the source code  , here you have one sample that I got from the net ( I remember I did something similar):
<br />
void main( VOID )<br />
{<br />
STARTUPINFO si;<br />
PROCESS_INFORMATION pi;<br />
<br />
ZeroMemory( &si, sizeof(si) );<br />
si.cb = sizeof(si);<br />
ZeroMemory( &pi, sizeof(pi) );<br />
<br />
if( !CreateProcess( NULL,
"MyChildProcess",
NULL,
NULL,
FALSE,
0,
NULL,
NULL,
&si,
&pi )
) <br />
{<br />
ErrorExit( "CreateProcess failed." );<br />
}<br />
<br />
WaitForSingleObject( pi.hProcess, INFINITE );<br />
<br />
CloseHandle( pi.hProcess );<br />
CloseHandle( pi.hThread );<br />
}<br />
HTH
Braulio
|
|
|
|
|
Hi, all:
I have a weird problem and need your help. I have a main app and DLL. In the main app I have my object pointer (CMyObj* pObj) that has method like:
HRESULT TranslateIDToName( long lID, LPSTR cBuff, UNIT dwBuffSize );
this TranslateIDToName then calls some methods in DLL.
In main, I have something like this:
const DWORD dwBuffSize = 128;
TCHAR cBuff[dwBuffSize];
pObj->TranslateIDToName( lID, cBuff, dwBuffSize );
When I compile both main app and DLL in RELEASE, (both uses Multithreaded DLL as Runtime DLL ). It works fine! However, if I compile both in Debug ( both uses Debug Multithreaded DLL ), I step through the code, The TranslateIDToName() fills up the cBuff correctly and then return from the function.
The problem comes when the function returns to the caller:
pObj->TranslateIDToName( lID, cBuff, dwBuffSize );
The pObj is trashed with either garbage in the pObj or pObj = NULL. In either case, the pObj address changes before calling the method and right after return from the method ( the Stack really messed up!!). Of course, the app crashes!
I tried all the stuff I can think of, and no more ideas about what could be wrong.
Any suggestion and help will be highly appreciated. Thanks in advance.
Dion
|
|
|
|
|
Are you sure the right DLL is being used? I mean, look in the working directory of the program, system directory etc. for your DLL, maybe by the DLL lookup rules a different version than you intended is being loaded.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I got the problem fixed. the problem is the array index out of range inside the function. thanks anyway.
|
|
|
|
|
Throw exception when start:
TypeLoadExeption: Can't find type: _IMAGELIST from assembly.....
Why?
|
|
|
|
|
KB320082 BUG: HTREEITEM May Cause TypeLoadException in a Managed C++ Application.
IMAGELIST is the same.
|
|
|
|
|
The ActiveX control created with ATL/WTL failed to be used in other develop tools, such as VB, PB. The system warning that "Failed to save the binary data of the object", I don't usderstand what it mean. do you know why?
|
|
|
|
|
The control probably failed to persist (or doesn't support persistance).
|
|
|
|
|
I thought the interface template IPersistStreamInitImpl had implemented the persistence. I overwirite the load and save methods, it is OK now!
Thanks a lot!
|
|
|
|
|
When used dynamicaly in a composite ActiveX control, the member funcion "create" of CDateTimePickerCtrl failed (the HWND returned is NULL).
Any advice will be appreciated, and Thak you in advance!
|
|
|
|
|
|
I have called InitCommonControls(), but create failed yet, do you have other advice,
thank you anyway!
|
|
|
|
|
Hi,
I had the same problem with the "cool" control ( comboBoxEx and DateTimePicker), I solve it in this way:
// ----
// Trying to register Combo box Ex
INITCOMMONCONTROLSEX iccex = { sizeof(INITCOMMONCONTROLSEX), ICC_USEREX_CLASSES };
InitCommonControlsEx(&iccex);
InitCommonControls(); // Obsolete remove if not necessary
// ----
It seems that InitCommonControlsEx works better
HTH
Braulio
|
|
|
|
|
Except do as you say, I have to copy the comctrl32.dll to the working derectory,
Thank you anyway!
|
|
|
|
|
Hi everyone,
First, I'd like to say that I'm new to both ATL and Shell Extension programming, and I'm running into a brick wall the last three day. I would like to ask for your expertise of the topic.
Currently, I'm working on a UI design of an ATL project. On one the UI, I have an embedded Window Explorer. Thanks a little trick from Matthijs Hollemans's Windows Explorer wildcard selection shell extension article, I was able to get the hold of the right-hand side window, which is a list view, of the embedded explorer. However, when I try to used the API function SHGetPathFromIDList trying to get the path of the list view item pidl (i.e: item.LPARAM), it always returns that path to the desktop. For example, if the selected file is C:\Test.txt, the API function would return C:\Documents and Settings\CurrentUserID\Desktop\Test.txt. It doesn't matter what directory you navigate to, the returned path is always the desktop. Two questions raised for me:
1. Is there a way to just query for the directory path of the embedded window explorer?
2. How and what are the steps do I need to take to resolved the extension issues in this specific scenario?
Thanks so much for your help
Here is the class I used to create the embedded Window Explorer
class CDirFileView : public CWindowImpl<cdirfileview, caxwindow="">
{
public:
DECLARE_WND_SUPERCLASS(NULL, CAxWindow::GetWndClassName())
BOOL PreTranslateMessage(MSG* pMsg)
{
if((pMsg->message < WM_KEYFIRST || pMsg->message > WM_KEYLAST) &&
(pMsg->message < WM_MOUSEFIRST || pMsg->message > WM_MOUSELAST))
return FALSE;
// give HTML page a chance to translate this message
return (BOOL)SendMessage(WM_FORWARDMSG, 0, (LPARAM)pMsg);
}
BEGIN_MSG_MAP(CDirFileView)
END_MSG_MAP()
// Handler prototypes (uncomment arguments if needed):
// LRESULT MessageHandler(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL& /*bHandled*/)
// LRESULT CommandHandler(WORD /*wNotifyCode*/, WORD /*wID*/, HWND /*hWndCtl*/, BOOL& /*bHandled*/)
// LRESULT NotifyHandler(int /*idCtrl*/, LPNMHDR /*pnmh*/, BOOL& /*bHandled*/)
BOOL DestroyWindow()
{
return CWindowImpl<cdirfileview, caxwindow="">::DestroyWindow();
}
};
|
|
|
|
|
I have a non-MFC project using std::string that is compiled into a library (Confetti.lib). My main project is an MFC project that uses this library. I get the following linker errors:
msvcprtd.lib(MSVCP70D.dll) : error LNK2005: "public: __thiscall std::basic_string<char,...>::~basic_string<char,...>(void)" (??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in Confetti.lib(ParticleSystem.obj)
msvcprtd.lib(MSVCP70D.dll) : error LNK2005: "public: __thiscall std::basic_string<char,...>::basic_string<char,...>(char const *)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z) already defined in Confetti.lib(ParticleSystem.obj)
Can anyone tell me why this is happening and how to fix it?
Also, if I ignore msvcprtd.lib, then I get lots of dll import/export errors for std::basic_string.
|
|
|
|
|
What's your code generation for both? Multithreaded, singlethreaded, dll, etc?
Steve S
|
|
|
|
|
Both are multithreaded.
However, I found that linking with the MFC DLL causes linker errors, and linking statically does not. My guess is that for some weird reason (a bug?), the MFC DLLs export some STL symbols.
|
|
|
|
|
I just dont get it, WTL´s DDX facilities define a DDX_CONTROL() macro that take an ID for a control, and an object to attach it to.
However, if i do something like this:
BEGIN_DDX_MAP(CMyDlg)
DDX_CONTROL(IDC_MYEDIT, m_cEdit)
END_DDX_MAP()
where IDC_MYEDIT is (of course) and edit box on my dialog, and m_cEdit is a member variable of type CEdit, then this class wont complie! because SubClassWindow() (witch is called by ddx), is NOT a member of CEdit!, i suppose i could write a class derived from CWindowImpl<derivedclass, cedit=""> and pass objects of it to DDX_CONTROL(), but i assumed that the whole purpuse of DDX was to make mi life easyer not harder!, it would be FAR more trouble to write a class for EVERY type of control i want to use DDX with, than just create control class member variables on my dialog, and just Attach() them to the "physical" controls on the dialog, early on my OnInitDialog() function!
Im i missing something???
what is the purpuse of DDX_CONTROL() if it CANT be used "normally" with controls?
|
|
|
|
|
DDX_CONTROL requires a class with a message map, that is, a CWindowImpl-derived class. The control wrappers are all CWindow-derived, so they can't be used with DDX. You need to do something like:
class CEditImpl : public CWindowImpl<CEditImpl, CEdit>
{ public: DECLARE_EMPTY_MSG_MAP() };and use CEditImpl for your m_cEdit variable. Yes, it's a hassle. 
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Ericahist updated Aug 30!
|
|
|
|
|
You can try CContainedWindowT<cedit>.
Regards,
Lirong
|
|
|
|
|
Thanks for your answers Michael & Li, i know i need a CWindowImpl derived class to do the job, but what i mean is, i dont understand the phylosofy (pardon my spelling if wrong, english is not my native language) of the creators of WTL in this issue, because what DDX_CONTROL is supposed to do, its easier done -without- DDX_CONTROL!.
I find it "harder" (more time consuming) to have to write a class(even a small one) for every type of control i want to use, include the proper headers on my dialog class, add the ddx map entry, etc., than just declaring a member variable like CEdit m_MyEdit, or CListViewCtrl m_MyList, etc. and just attaching it via their Attach() method on my dialog´s OnInitDialog(), my point is ¿whats the design concept behind DDX_CONTROL? or in other words, ¿when do you actually use DDX_CONTROL because its easier to do so?
|
|
|
|
|
Ernesto D. wrote:
declaring a member variable like CEdit m_MyEdit, or CListViewCtrl m_MyList, etc. and just attaching it via their Attach() method on my dialog´s OnInitDialog(),
I would rather have a map in the header file, which is easy to find and edit, than calls to Attach(GetDlgItem(IDC_FOO)) over and over. The code to hook up all the controls at once with DDX is just one line, DoDataExchange(false); Using Attach() will work just as well, if that's the way you prefer.
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Ericahist updated Aug 30!
|
|
|
|
|
We converted some of our small-size projects to WTL previously. Now we are skeptical putting more effort on WTL, as Microsoft now seems don't even want to improve MFC/ATL beside keep pushing (implicitly forcing...) .nut for C/C++, which in our view, would eventually kill C/C++ on Windows. 
Anyone with any idea is WTL dead? 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
