C / C++ / MFC

23-Sep-01 2:03

HI ALL
======

My Code goes a little bit like this:

func1() { func2(); }
func2() { func3(); }
func3() { func4(); }
func5() { func6(); }
func6() { <code>throw;</code> }
 
void thread_main_func()
{
  ...
  ...
  ...
try { func1(); }
catch (...)
{
}
}

Do I need and how to clear the call stack ?

BTW: come to #CodeProject on DalNet (mIRC)

BTW: come to #CodeProject on DalNet (mIRC)

Christian Graus23-Sep-01 2:36

Christian Graus

23-Sep-01 2:36

Sorry, did I forget to specify ? Stroustrup states that try/catch/throw unwinds the stack for you.

I don't know of any way of doing it yourself, actually.

Christian

As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.

Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.

The_Server23-Sep-01 3:30

23-Sep-01 3:30

thanks for your help.

but I'm having trouble understanding what is "Stroustrup"?
didn't find "Stroustrup" on MSDN.

please expand you knowledge about this "Stroustrup" thing.

thanks

BTW: come to #CodeProject on DalNet (mIRC)

Tim Smith23-Sep-01 3:36

Tim Smith

23-Sep-01 3:36

He is the author of C++.

Tim Smith
Descartes Systems Sciences, Inc.

The_Server23-Sep-01 3:50

FILE pointer to DLL function

23-Sep-01 3:50

23-Sep-01 1:10

Why can't I use a FILE* pointer to a DLL-function? My program hangs when I try! Confused | :confused:

C^hris L^osinger23-Sep-01 3:34

C^hris L^osinger

23-Sep-01 3:34

because a DLL function isn't a FILE. ?

(you might want to rephrase the question)

-c

------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com

23-Sep-01 5:09

Use a FILE pointer as a PARAMETER to a DLL-function.
When I write to the file from my DLL, the program hangs!

23-Sep-01 6:57

The problem is that a FILE pointer references data in your calling DLLs C-library. If this C-library is different from the C-library the callee uses the program will hand or crash.
Solution: use the same copy of the C-library in both DLLs, e.g. by checking the option "use MFC in shared library" in BOTH projects.

Anyway: using a FILE pointer in an interface is not the best programming style Wink | ;-)

best regards
Carsten

23-Sep-01 10:21

Thanks for your answer!

If using a FILE pointer as a DLL function parameter is not a good programming style, what type of file object should I use instead? I don't use the MFC in my either my main program, or my DLL.
The run time library in my DLL is set to "Multithreaded", but the one in my main program is "Single-threaded". If i set both of them to "Multithreaded", not all the data I write to the FILE from the DLL gets written!

Erik

C^hris L^osinger23-Sep-01 7:08

C^hris L^osinger

23-Sep-01 7:08

see Q190799 "PRB: Potential Errors Passing CRT Objects Across DLL Boundaries" in the MSDN

-c

------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com

Call Stack

The_Server22-Sep-01 20:37

22-Sep-01 20:37

HI ALL
======

My Code goes a little bit like this:

 func1() { func2(); }
func2() { func3(); }
func3() { func4(); }
func5() { func6(); }
func6() { goto THREAD_END; }
 
void thread_main_func()
{
  ...
  ...
  ...
THREAD_END:
  ...
  ...
}

Do I need and how to clear the call stack ?

BTW: come to #CodeProject on DalNet (mIRC)

Re: Call Stack

Christian Graus23-Sep-01 0:57

Christian Graus

23-Sep-01 0:57

What you need to do is realise that if you're using goto there is always a better, less satanic way. Wink | ;)

Using try/catch/throw works better because unlike goto, it's still clear that all your code is headed in the same direction.

Stroustrup is not clear on the question, but I looked up goto in the index and got page 357. which does not mention goto and is about exceptions. It seems to imply try/throw.catch is a better solution stack-wise, but is not clear cut. So I'd not hang my hat on that statement.

Christian

As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.

Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.

Non-Modal dialog

22-Sep-01 12:21

Hi
I think this question has been asked a hundret times already, but I hope someone wanst to help me anyway Smile | :)

I want to show a new dialog, but not with DoModal, the dialog needs to be non-modal.

how can I do this?
I'm using MFC and a dialog-based app

thanks in advance

Michael P Butler22-Sep-01 12:30

Michael P Butler

22-Sep-01 12:30

For a child of the main dialog, you'll need code similar to this

m_MyModelessDialog.Create(IDD_DIALOGRESOURCE, this);

m_MyModelessDialog.ShowWindow(SW_SHOW);

22-Sep-01 12:33

I already have this code

CWndTest dlg;
dlg.Create(IDD_MYDIALOG,this);
dlg.ShowWindow(SW_SHOW);

but the windows does not appear

Joaquín M López Muñoz22-Sep-01 12:38

Joaquín M López Muñoz

22-Sep-01 12:38

Don't have dlg defined as a local variable: that causes the dialog to be destroyed as soon as you exit from the function where you defined it; instead, create it on the heap with CWndTest *pDlg=new CWndTest() and make the dialog delete itself on WM_POSTNCDESTROY. See the documentation of your compiler on modeless dialogs.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

22-Sep-01 12:44

Thanks a lot! Smile | :)

But where do I need to put the "delete pDlg"?

Michael P Butler22-Sep-01 12:47

Michael P Butler

22-Sep-01 12:47

I tend to put mine in the PostNCDestroy function and do a

delete this.

Michael

22-Sep-01 12:51

and what happens to the pointer pDlg?
Will it be deleted with this call?

And how can I override PostNCDestroy?

One newbie, many stupid questions Smile | :)

22-Sep-01 13:07

Ok, I found out, works perfect Smile | :)

THANKS!!!! Smile | :)

One final question:

Can I use AfxGetMainWnd() to get a pointer to the dialog who called the new dialog or what do I need to do?

Ravi Bhavnani22-Sep-01 13:58

Ravi Bhavnani

22-Sep-01 13:58

Use GetParent().

/ravi

"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com

Christian Graus22-Sep-01 12:42

Christian Graus

22-Sep-01 12:42

Yeah, it does. Because your variable is local, the dialog appears for a split second, the variable goes out of scope, and is destroyed. You need to make the dialog a member variable, you can use a pointer, and check for NULL to see if it's visible or not, or use ::IsWindow, in which case you can make it an instance of the class.

I do this in the constructor of my modeless dialogs

if (Create(pParent, IDD)) ShowWindow(SW_SHOW);

and use pointers, then when I call new on the pointer, the dialog comes up right away.

Christian

As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.

Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.