|
I have an external application that launches my application. I have a global variable that determines whether my app was launched via the other app or just by opening the executable. If launched via the other application, two processes or instances gets created and the global variable is set to 1. The first instance will be created but the window frame will not be shown. The other instance will display the window. One instance has the global value initialized to 0 while the other one has it set to 1. I need to block the instance that has global variable = 0 and let the other one run. Once that thread completes, I want the other thread (I believe it’s the main thread) to continue running. I tried using a mutex around my code but it still seems to be doing context-switching. How can I put a hold on thread1? I’ve tried using events but no such luck. This is what I have. Thanks!
<pre>
InitInstance()
{
mutex = ::CreateMutex(NULL, FALSE, “X”);
if(mutex==NULL)
{
AfxMessageBox("Error: Problem with creating the mutex");
return FALSE;
}
else {
WaitForSingleObject(mutex, INFINITE);
if (!bGlobalVariable)
{
OneInstance = ::CreateMutex(NULL, FALSE, “instance”);
DWORD dwMutexErr = GetLastError();
if (dwMutexErr == ERROR_ALREADY_EXISTS)
return FALSE;
}
ReleaseMutex(mutex);
}
if (!GlobalVariable)
//show window
return TRUE;
}
</pre>
-- modifed at 17:51 Thursday 25th August, 2005
|
|
|
|
|
I'm looking for ideas. I have an embedded application that must respond to a changing system environment. A good analogy would be a loosely networked set of PCs. My application (SDI, but heavy on dialogs) monitors this system and allows the user to program it. If everything is stable, then I have no problems. The issues start when I have a 4 node system, and the 2nd node drops out. Because of my dialog layers, I could easily be 4 layers into dialogs when this occurs.
Is there any way to cleanly "unwind" from my dialog stack in a programmatic fashion?
Still learning...
C. Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
|
|
|
|
|
I could not undersstand the following line ..
Is there any way to cleanly "unwind" from my dialog stack in a programmatic fashion?
...ill be better if u come up with a detailed description of the issue
redindian
|
|
|
|
|
unwind is the best word I could come up with.... this is what my GUI looks like in a very simple fashion:
m_pMainWnd...
CMyDialog1 myDlg(this);
myDlg.doModal();
and again and again. In essence I have a stack of dialogs one on top of the other. Suppose this stack is 6 dialogs deep, how do I get out of the stack of dialogs back to the main window? Usually, the user would press continue, cancel, etc. and navigate their way back. I need to be able to do it automagically via code...
did that help?
C. Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
|
|
|
|
|
r these dialogs modal or non modal?
"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13
-- modified at 5:47 Friday 26th August, 2005
|
|
|
|
|
Good morning - these dialogs are all modal...
C. Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
|
|
|
|
|
Good Morning!
hmmmm.....modal!.....well if those were non modal,u could post a message to the previous windows to close,then destroy the topmost one!....
since this is modal,all the dialogs run on the same thread!.....
i am not sure,but try the following out!
on the button click of the topmost modal dialog,a function say 'buttonclick()' should be called.This function should post a message(make that a userdefined message) to its immediate parent which would trigger a function say funct1()in itz parent.
Then,this 'buttonclick()'function should close the topmostdialog.
//NOW THE TOPMOST DIALOG CLOSES,AND ITS PARENT BECOMES THE TOPMOST.
now this message which was posted to the parent by the ex-topmostdialog gets recieved,and gets processed by the function corresponding to the message that was sent by its child(or the ex-topmost dialog).....this function in the parent called 'funct1()' should do the same process as done by the 'buttonclick()'function.....
use this technique,and u should be able to get as desired!....please note that ,i havent tried this out!justa solution.....
if u want to know how to send user defined messages and handle them just go thru the following link.....(try the WM_APP: constant messages,they should be easy to setup!)
http://www.codeproject.com/dialog/messagemgmt.asp[^]
cheerz.....
"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13
|
|
|
|
|
Ha! I love how requirements change. Since this is an intellectually challanging design issue, I'll continue to poke around. But, I have just learned that should a system component go away (triggering the need to unwind), the entire system is going to reset (means I lose power to my system). Poof, issue resolved.
Nothing like rebooting to unwind the stack of dialogs eh?
Thanks for all your suggestions, they've given me something to work with and concepts to study.
C. Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
|
|
|
|
|
Hi,
I am using TreeView.TopNode to get the first root node of my treeview. This does not work for me all the time however. If you read the .NET Framework on this property, I think they state this also by saying:
Initially, the TopNode returns the first root tree node, which is located at the top of the TreeView. However, if the user has scrolled the contents, another tree node might be at the top.
I don't understand why the TopNode would return a different node after a user scrolled through the treeview. Does anybody know why? And in this case, how else could I get the first root node? Thanks.
TraileR ParK LifE 4Ever
|
|
|
|
|
One way would be to get the top node and save it in a member variable. That way you'll always have access to the top node no matter what amount of scrolling has transpired.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Thanks for the reply David. I simply chose to just get the first root node through the treeview.Nodes.get_Item(0) property, like Jose suggested but your way definitely works as well. Thanks.
TraileR ParK LifE 4Ever
|
|
|
|
|
/*Trucker*\ wrote:
I simply chose to just get the first root node through the treeview.Nodes.get_Item(0) property, like Jose suggested...
Which is a much cleaner solution. I'm not familiar with the .Net stuff so some of my answers are not always straight forward.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
TopNode returns "the first fully-visible tree node in the tree view control". That is, it only considers those nodes that are currently visible, and that's why its result may vary if the user has scrolled.
If what you want is the absolute first root node, I think it should be the first element of the collection you get through the Nodes propety.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Ofcourse! Here I go again thinking 'inside the box';P. Although I don't see the use of a function like TopNode that returns the first fully visible node... I mean cmon, who would want to get a node like that? Anyways, your answer is exactly what I was looking for. Thanks again
TraileR ParK LifE 4Ever
|
|
|
|
|
How to check if a thread is Alive or not?.. ie CWinThread *cwt;
cwt->isAlive()?? nothing like that? . plz help
V
-- modifed at 13:01 Thursday 25th August, 2005
|
|
|
|
|
You can pass the thread handle to GetExitCodeThread - it will return STILL_ACTIVE if the thread is alive.
He is smart. He will make our Windows go.
|
|
|
|
|
See here.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
What I really like to do is using events. I usually create 3 handles, hStartup, hStopNow, hShutdown. I use hStartup for the thread to signify the thread started, hStopNow to signal the thread to stop (if it's needed) and hShutdown as the signal to acknowledge and that the thread has indeed stopped. I don't know if this is helpful or not depending on how you are actually using threads. This method lets me have more control in synchronizing the thread to my function. If data needs to be passed to the thread to be done, more handles are used to handoff data to and from the thread. I'll be willing to elaborate further here if you want, simply reply and ask for more information here.
|
|
|
|
|
what does the method ExitInstance()'d actually do?
Thanks ,
V
|
|
|
|
|
Hi,
I am working on an MDI application, and I want to add a progress dialog box to a member function of a class (which is generic). I used the ProgressDlg automatically created by Visual C++ components. It has a Create function (btw, it is not overwriting the CDialog Create), that looks like this:
<br />
BOOL CProgressDlg::Create(CWnd *pParent)<br />
{<br />
m_pParentWnd = CWnd::GetSafeOwner(pParent);<br />
<br />
<br />
if((m_pParentWnd!=NULL) && m_pParentWnd->IsWindowEnabled())<br />
{<br />
m_pParentWnd->EnableWindow(FALSE);<br />
m_bParentDisabled = TRUE;<br />
}<br />
<br />
if(!CDialog::Create(CG_IDS_PROGRESS_CAPTION,pParent))<br />
{<br />
ReEnableParent();<br />
return FALSE;<br />
}<br />
<br />
return TRUE;<br />
}<br />
I thought that it was fair to create this dialog with a NULL parent window. But its weird that the call to CWnd::GetSafeOwner(NULL) returns a valid parent window, and then the CDialog::Create crashes.
So, I tried passing AfxGetMainWnd() but that crashes too. Is it because I am in an MDI app??
Does anyone know how to successfully create an object of this derived CDialog class?
I would appreciate any help.
Thanks
|
|
|
|
|
Have you stepped into CDialog::Create() to see exactly which statement is "crashing?"
When I make a modeless dialog, I use:
class CProgressDlg : public CDialog
{
public:
enum { IDD = IDD_PROGRESS_DIALOG };
virtual void PostNcDestroy();
};
CProgressDlg::CProgressDlg(CWnd* pParent)
: CDialog(CProgressDlg::IDD, pParent)
{
Create(IDD);
}
void CProgressDlg::PostNcDestroy()
{
delete this;
CDialog::PostNcDestroy();
}To use it:
CProgressDlg *pDlg = new CProgressDialog;
pDlg->ShowWindow(SW_SHOW);
pDlg->DestroyWindow(); Does that help?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
The assertion is caused when CWnd::CreateDlgIndirect(LPCDLGTEMPLATE lpDialogTemplate,
CWnd* pParentWnd, HINSTANCE hInst) is called and lpDialogTemplate is NULL.
<br />
CDialog::Create(LPCTSTR lpszTemplateName, CWnd* pParentWnd)<br />
{<br />
.....<br />
BOOL bResult = CreateIndirect(hTemplate, pParentWnd, hInst);<br />
<br />
}<br />
<br />
<br />
BOOL CDialog::CreateIndirect(HGLOBAL hDialogTemplate, CWnd* pParentWnd,<br />
HINSTANCE hInst)<br />
{<br />
ASSERT(hDialogTemplate != NULL);
<br />
LPCDLGTEMPLATE lpDialogTemplate = (LPCDLGTEMPLATE)LockResource(hDialogTemplate);<br />
BOOL bResult = CreateIndirect(lpDialogTemplate, pParentWnd, NULL, hInst);
UnlockResource(hDialogTemplate);<br />
<br />
return bResult;<br />
}<br />
<br />
<br />
BOOL CDialog::CreateIndirect(LPCDLGTEMPLATE lpDialogTemplate, CWnd* pParentWnd,<br />
void* lpDialogInit, HINSTANCE hInst)<br />
{<br />
ASSERT(lpDialogTemplate != NULL);<br />
<br />
if (pParentWnd == NULL)<br />
pParentWnd = AfxGetMainWnd();
m_lpDialogInit = lpDialogInit;
<br />
return CreateDlgIndirect(lpDialogTemplate, pParentWnd, hInst);<br />
}<br />
<br />
BOOL CWnd::CreateDlgIndirect(LPCDLGTEMPLATE lpDialogTemplate,<br />
CWnd* pParentWnd, HINSTANCE hInst)<br />
{<br />
ASSERT(lpDialogTemplate != NULL);<br />
....<br />
hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,<br />
pParentWnd->GetSafeHwnd(), AfxDlgProc);
<br />
<br />
<br />
}<br />
<br />
Swati
-- modifed at 14:43 Thursday 25th August, 2005
|
|
|
|
|
|
Further to your message, I'll restate the problem:
I am using a class CProgressDlg which is derived from CDialog. I am creating a modeless dialog in a generic class, so I use something like this:
CProgressDlg dlg;
dlg.Create(NULL);
where the Create function is as shown in the first email. This function throws an ASSERT failure. I think the problem is due to the fact that CDialog creates a dialog with parent wnd as AfxGetMainWnd() which returns a CMDIFrameWnd() as opposed to CMainFrame() in an SDI app. I have used this CProgressDlg class before in an SDI app and had no problems, and the only difference I can see is this.
Am I clearer now?
Swati
|
|
|
|
|
C
swati24 wrote:
BOOL CWnd::CreateDlgIndirect(LPCDLGTEMPLATE lpDialogTemplate,
CWnd* pParentWnd, HINSTANCE hInst)
{
ASSERT(lpDialogTemplate != NULL);//ASSERTION FAILURE
....
}
Sorry I misquoted the above, lpDialogTemplate is not NULL.
BOOL CWnd::CreateDlgIndirect(LPCDLGTEMPLATE lpDialogTemplate,
CWnd* pParentWnd, HINSTANCE hInst)
{
....
hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate,
pParentWnd->GetSafeHwnd(), AfxDlgProc); //CAUSES ASSERTION FAILURE
//pParentWnd is not NULL
...
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
