|
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
...
}
|
|
|
|
|
Hi,
Firstly, yes it helps.
You see earlier I had this function called:
<br />
BOOL CProgressDlg::Create(CWnd* pParent)<br />
{<br />
CDialog::Create(CProgressDlg::IDD, pParent);<br />
}<br />
and this crashed when I did:
<br />
CProgressDlg* pDlg = new CProgressDlg();<br />
pDlg->Create(NULL);<br />
But now I got rid of Create function and added Create(IDD) in the constructor and it works. Do you know why?
Swati
|
|
|
|
|
Hi,
The user have an ability to change a Windows font size and type(Display Properties/Apperance/Font Size: Normal, Extra Large, Large), and those changes affect my application fonts, dialog boxes, some controls, etc...
I just need an advice, what the best way to handle it in the GUI.
And another question.
Can I some how to preserve my application's default font(MS Sans Serif size 8) from overriding by Windows?
Thanks.
|
|
|
|
|
Hi,
Does anyone know which sytem colour is used for the background of the task pane shown on the left hand edge of Windows Explorer windows in XP?
Thanks
Joel Holdsworth
|
|
|
|
|
Not exactly. But you can use the Display applet's Appearance tab (rundll32 shell32.dll,Control_RunDLL desk.cpl,,2) in Control Panel and GetSysColor() to figure it out.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-- modifed at 14:02 Thursday 25th August, 2005
|
|
|
|
|
Yeah that's the funny thing... I can't figure it out. I don't think I'm being stupid, but I can't find where this colour comes from! I think it comes from the theme itself somehow, but I'm not sure!
Joel Holdsworth
-- modified at 3:53 Friday 26th August, 2005
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
