|
|
THANKS!! That worked perfectly
If it's broken, I probably did it
bdiamond
|
|
|
|
|
Don't remember where I picked this up but most likely somewhere here...Best site around!!
BOOL LaunchChild(LPCSTR lpszCmdLine, BOOL bShowChildWindow)
{
HANDLE hProcess = ::GetCurrentProcess();
PROCESS_INFORMATION pi;
STARTUPINFO si;
::ZeroMemory(&si, sizeof(STARTUPINFO));
si.cb = sizeof(STARTUPINFO);
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = bShowChildWindow ? SW_SHOW: SW_HIDE;
LPVOID lpSD = NULL;
LPSECURITY_ATTRIBUTES lpSA = NULL;
lpSD = ::GlobalAlloc(GPTR, SECURITY_DESCRIPTOR_MIN_LENGTH);
::InitializeSecurityDescriptor(lpSD, SECURITY_DESCRIPTOR_REVISION);
::SetSecurityDescriptorDacl(lpSD, -1, 0, 0);
lpSA = (LPSECURITY_ATTRIBUTES)::GlobalAlloc(GPTR, sizeof(SECURITY_ATTRIBUTES));
lpSA->nLength = sizeof(SECURITY_ATTRIBUTES);
lpSA->lpSecurityDescriptor = lpSD;
lpSA->bInheritHandle = TRUE;
BOOL bResult = ::CreateProcess(NULL, (LPTSTR)(LPCTSTR)lpszCmdLine, lpSA, NULL, TRUE,
CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi);
if (lpSA != NULL)
::GlobalFree(lpSA);
if (lpSD != NULL)
::GlobalFree(lpSD);
if (!bResult) return FALSE;
::CloseHandle(pi.hThread);
::CloseHandle(pi.hProcess);
return bResult;
}
Just pass in the command line and whether or not you want the console window displayed.
Thanks to whomever submitted this!
ed
The absence of evidence is not evidence of absence.
|
|
|
|
|
thanks ed, but the answer I got before yours worked perfectly and it only uses one line:
ShellExecute(NULL,"open","dtsrun.exe","/S localhost /U admin /P admin /N ImportDistTextToTable",NULL,SW_HIDE);
If it's broken, I probably did it
bdiamond
|
|
|
|
|
Actually his way defines the whole function... good way to learn... and his function takes in less parameters and too could be in one line of code
Actual Linux Penguins were harmed in the creation of this message.
|
|
|
|
|
But it also requires an NT kernel operating system.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I am writing an application that performs custom titlebar painting. I have been using Paul DiLascia's CCaptionPainter class to accomplish this. Things have been working fairly well until I have come across a problem with modeless dialogs(a debug ASSERT_VALID). My main application is where the title bar painting occurs. I have various submenus that launches various other dialogs. I have noticed that when I launch a modeless dialog and move it, the OnNcPaint routine in my CCaptionPainter class ASSERT_VALID(m_pWndHooked) /*class member CWnd object reference*/ produces the following assertion in WinCore.cpp. I have googled the below snippet from WinCore.cpp, but have not come up with anything that makes sense. I am not passing my CWnd object from thread to thread and am wondering if anyone has seen other variations of this assertion. Thanks!
CObject* p;
ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||
(p = pMap->LookupTemporary(m_hWnd)) != NULL);
ASSERT((CWnd*)p == this); // must be us
// Note: if either of the above asserts fire and you are
// writing a multithreaded application, it is likely that
// you have passed a C++ object from one thread to another
// and have used that object in a way that was not intended.
// (only simple inline wrapper functions should be used)
//
// In general, CWnd objects should be passed by HWND from
// one thread to another. The receiving thread can wrap
// the HWND with a CWnd object by using CWnd::FromHandle.
//
// It is dangerous to pass C++ objects from one thread to
// another, unless the objects are designed to be used in
// such a manner.
|
|
|
|
|
You should ASSERT(IsWindow(p->GetSafeHwnd()) which check the validity of your Hwnd
Sonork 100.41263:Anthony_Yio
Life is about experiencing ...
|
|
|
|
|
hi everyone,
i've started doing my first 'really multithreaded' app. i've inherited the CWinThread, thus creating an interface thread. the problem is, that i sometimes run into some trouble. but first, the code (without project )
<br />
BOOL CFilesystemThread::InitInstance()<br />
{<br />
TRACE("Filesystem thread init....");<br />
m_pFilesystemDlg = new CFilesystemDlg();<br />
m_pFilesystemDlg->Create( IDD_FILESYSTEM_DIALOG,<br />
CWnd::GetDesktopWindow() );<br />
m_pFilesystemDlg->ShowWindow( SW_SHOW );<br />
<br />
TRACE("..done!\n");<br />
return TRUE;<br />
}<br />
<br />
thread exit:<br />
<br />
int CFilesystemThread::ExitInstance()<br />
{<br />
TRACE("Filesystem thread stop....");<br />
if ( m_pFilesystemDlg )<br />
{<br />
m_pFilesystemDlg->DestroyWindow();<br />
delete m_pFilesystemDlg;<br />
m_pFilesystemDlg = NULL;<br />
}<br />
<br />
TRACE("..done!\n");<br />
return CWinThread::ExitInstance();<br />
}<br />
<br />
void CCNWServerDlg::OnBnFilesystem() <br />
{<br />
if ( g_dataEx.filesystem.pFilesystemInterface.IsLoaded() )<br />
{<br />
if ( g_dataEx.pFilesystemThread == NULL )<br />
{<br />
g_dataEx.pFilesystemThread = (CFilesystemThread*)<br />
AfxBeginThread( RUNTIME_CLASS( CFilesystemThread ) );<br />
}<br />
else<br />
{<br />
g_dataEx.pFilesystemThread->m_pFilesystemDlg->ShowWindow( SW_RESTORE );<br />
g_dataEx.pFilesystemThread->m_pFilesystemDlg->SetForegroundWindow();<br />
}<br />
}<br />
else<br />
{
MessageBox(<br />
"Error loading filesystem module!",<br />
"Fatality", MB_OK|MB_ICONSTOP );<br />
}<br />
}<br />
<br />
---<br />
if ( g_dataEx.pFilesystemThread != NULL )<br />
{<br />
g_dataEx.pFilesystemThread->ExitInstance();<br />
delete g_dataEx.pFilesystemThread;<br />
}<br />
the final result is that if i run ONLY the filesystem thread, it goes down gracefuly. if i run for example accounts thread AND the filesystem i get this:
debug window:
Accounts thread init.
Accounts thread stop.
Filesystem thread stop......done!
Second Chance Assertion Failed: File wincore.cpp, Line 304
message box:
User breakpoint called from code at 0x77f7f570. (disassembly opens, which i don't know nothing about..)
em...SO. if you have any clue what happens, and where i'm doing things wrong, PLEASE help. anyone..?
---
kick ash.
http://sprdsoft.bigmoron.com
http://t1tan.cjb.net
|
|
|
|
|
I have been using multithreading with MFC for over 5 years and in my experience you will run into problems if you do any GUI code in a thread that is not the main window thread. You must never call any MFC gui code across thread boundries and never create any CViews in a thread that is not the main thread. This is because MFC uses thread local data to store a lot of its info about Doc and view. With that said your problem may be auto delete as CWinThread classes will automatically delete them selves on termination. You should disable this by setting m_bAutoDelete to FALSE and free the object yourself.
John
|
|
|
|
|
hi john,
i (obviously) forgot to mention that the app i'm doing is dialog based. i still can't figure it out: how can one thread affect the other, because my filesystem thread, when run alone, really works fine..?
i'll try the m_bAutoDelete thing, is there something i should know about it? is there a standard way everyone uses to stop a thread?
thanx
---
kick ash.
http://sprdsoft.bigmoron.com
http://t1tan.cjb.net
|
|
|
|
|
T1TAN wrote:
i (obviously) forgot to mention that the app i'm doing is dialog based.
Oh. I saw that, I'm sorry about the long rant about doc/view but you still have to be careful of GUI calls with dialog based apps.
Did you check the source for wincore.cpp, at Line 304? What version of VC are you using? I looked at my version of vc6 and it is not a valid instruction but it is exactly where I thought the problem to be. I mean it is between the CWnd::FromHandle(HWND hWnd) or CWnd::FromHandlePermanent(HWND hWnd). Niether of these functions will work accross threads.
[EDIT]
Ok line 304 in wincore.cpp is in VC7. Here:
CWnd* PASCAL CWnd::FromHandle(HWND hWnd)
{
CHandleMap* pMap = afxMapHWND(TRUE);
ASSERT(pMap != NULL);
The assert fails because the handle map is null when you are calling this member from a thread that did not create the window. This is fixed by putting the dialog in the main application thread.
[/EDIT]
John
|
|
|
|
|
argh, argv, argc...
John M. Drescher wrote:
I'm sorry about the long rant about doc/view
heh, it's better than saying nothing, is it?
i haven't checked it out (and i'm not at my PC right now..) but i sure will. so.. my dialog cannot be inside a thread? now that sucks. i really need to do this app multithreaded, because my app is a file exchange && chat server, and it would be really awkward to leave it single-threaded.
if you have any other ideas for making the app more responsive, now is the time and place
thanx again
---
kick ash.
http://sprdsoft.bigmoron.com
http://t1tan.cjb.net
|
|
|
|
|
T1TAN wrote:
so.. my dialog cannot be inside a thread?
You can but in a lot of cases you will run into problems like this. You must not have the parent of the dialog be the main window. You must not call any of the dialog's GUI calls from any other thread than the one the dialog was created in. You must not delete the dialog object from a thread that did not create it.
John
|
|
|
|
|
John M. Drescher wrote:
You can but in a lot of cases you will run into problems like this.
nothing is ever easy..
John M. Drescher wrote:
You must not have the parent of the dialog be the main window.
i made it so that the desktop window is the parent, without knowing this
John M. Drescher wrote:
You must not call any of the dialog's GUI calls from any other thread than the one the dialog was created in.
hm.. does that mean that i should send a message to thread, and then handle it so that the owner thread takes care of the dialog? a man's gotta do what man's gotta do..
thanks john, you're a great help
dst
---
kick ash.
http://sprdsoft.bigmoron.com
http://t1tan.cjb.net
|
|
|
|
|
T1TAN wrote:
does that mean that i should send a message to thread
Yes!
John
|
|
|
|
|
hi,
With what u have mention above, does it means that we cannot include any updates of the GUI codings in the thread function?
I have 2 MFC program, can i use just one button to control these 2 MFC?
Btw, this 2 MFC is link by a database(Microsoft Access). How can i run this 2 MFC concurrently and continously with just one Start button and will end it once i click on the Exit button.
And I tried using thread function with database. But it has some errors on the recordset that i have used. can u advice me on this issue?
Thanks lots..
dReaMerzZ
|
|
|
|
|
I get back on the rest if I have some time.
dreamerzz wrote:
And I tried using thread function with database. But it has some errors on the recordset that i have used. can u advice me on this issue?
This is because DAO is not multithreaded. There are workarounds for this but it is much better to use ADO to connect to the database. I use ado and connect with any of the threads in my program with no problems at all. A good ado article is here:
http://www.codeproject.com/database/caaadoclass1.asp
John
|
|
|
|
|
Hi,
Thanks for ur help and advice
dReaMerzZ
|
|
|
|
|
Sorry I did not get the rest of the info for you. I am behind on a very important deadline and I do not have a lot of time.
John
|
|
|
|
|
I know how to make a BSTR from a CString object but can't find the way to do the other way around.
Does anyone know how to create a CString object from a BSTR ??
|
|
|
|
|
Suppose you have :
BSTR b; // Allocate this by SysAllocString API
CString s;
then use:
s=b;
So simple.:-DOK It will work.
Regards,
Darshan Jani
|
|
|
|
|
Is this what you want ?
BSTR bstr = SysAllocString( L"abc" );
CString cs;
cs = bstr;
GuimaSun
www.nexsun.com.br
|
|
|
|
|
Hello,
At the moment I am outputing a bitmap on the screen and when it resizes etc. it redraws that bitmap ok. I need to output more bitmaps to the screen and when it need to be redrawn to display all of them. How can I do that? I tried double-buffering but I don't know how to add the "small" bitmaps to the off-screen bitmap.
Thanks
|
|
|
|
|
Hi,
I am trying to customize the CFileDialog. I want to have the select multiple files feature to turn on and off based on the user behavior (e.g. click a button on this customized dialog). Is it possible to do that ? I only know that it works only if I set the ofn flag to OFN_ALLOWMULTISELECT before intialize.
Thanks.
|
|
|
|