|
Well, MSDN certainly does list the problem but it refers to Visual Studio version 2003, I'm running 2002, in any event, the information that they list on MSDN does not really give a clue as to why this problem just happens out of the blue. I seem to be able to avoid this problem by removing Visual studio, and than reinstalling it, but I would like to know why the problem came up in the first place.
thanks for your feedback!
|
|
|
|
|
When you use the appwiz to create a MDI or SDI app, info about each menu item is shown in the statusbar when you hover over the menu item.
I have a dialog with a menu and a statusbar. Is there any good way to do this for me?
Øivind
|
|
|
|
|
you have an event WN_MENUITEM (if i remember).
then, you catch with the event-associated function the item ID and you'll be able to get the string table entry for this ID.
TOXCCT >>> GEII power
|
|
|
|
|
Hi!.
I'm writing an application that serialize some object.
So, I have a class called CObjectX, (this would be the object to serialize).
And I have 3 more classes CObjectA, CObjectB y CObjectC.
The class CObjectX have an array of CObjectA wich have also an array of CObjectB and CObjectC.
My questions are:
Should I derived from CObject too every class that it's referenced in COBjectX?.
For every header and implementation file of these objects should I write DECLARE_SERIAL(...) and IMPLEMENT_SERIAL(...)?.
And, finally, should I overwrite only the virtual function Serialize() of CObjectX?.
Thank you.
Demian.
|
|
|
|
|
|
Hi Ravi.
I'm still having troubles to serialize my object.
I have a class called: CDecDatabase that have a member of type CPtrArray of CSistema object, (an array of CSistema objects).
CSistema object have 3 arrays CPtrArray, (arrays of objects CP1, CP2 y CP3).
All the object have a Serialize function.
When
First I invoke CDecDatabase::Serialize(), then, this function call for every CSistema object in the array call CSistema::Serialize() and this function call the method Serialize() for every CP1, CP2 and CP3 object in the arrays.
Something I have saved but I can't load it.
I don't know if I'm serialize the objects in the right order.
Thank you.
Demian.
|
|
|
|
|
OK, you're almost there!
CDecDatabase::serialize() should first save the number (int) of CSistema objects in its CPtrArray, and then save each CPtrArray. Same for CSistema::Serialize() , which should first save the size of each CP array before saving the array itself.
When you want to read stuff in, first read the size of the array you're about to deserialize, then loop that many times and serialize each object and add it to the CPtrArray.
I must add more detail to the 3rd serialization article. That's where all the really interesting stuff is!
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Folks,
Is it legal to sell software developed with VS C++ 6.0 Standard Edition? I'm talking about garage shareware here, in case it makes any difference.
Be well people
|
|
|
|
|
|
I have an app that I want to run (dtsrun.exe) I can run it from the command line, but how do I do that in code with the specified switches? I know in vb I could use the ShellExecute() function, but how do I do that in C++ if I want to run this: 'dtsrun /S localhost /p jt'? thanks in advance for any help!!
If it's broken, I probably did it
bdiamond
|
|
|
|
|
|
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
|
|
|
|