Hello all, I was wondering about the scope of try...catch constructions over threads. An example (very simplified example of existing code, where the Main_thread acts like a scheduler and the Worker_Threads are the 'processes'):

Main_thread
{
try {
// Launch some Worker_threads
}
catch( ... ) {
// Do some actions
}
}

Worker_thread
{
try {
// The executing code, which might also execute
// the throw-function.
}
catch( condition ) {
// Do some actions, but continue operation
}
catch( ... ) {
// Do some actions
throw( something ); // should be catched in Main_Thread
}
}

Is it possible to (or 'how to') catch the last throw from the Worker_thread into the Main_thread? What is the nice way to do this? Thanks in advance, EiSl

Hello all, When walking through the stack (in my Unhandled Exception Handler) using StackWalk from dbghelp/imagehlp library, this function also provides me the parameters (max. 4) of the function called. Now... Where/how do they get that parameter info? Because I want to make a kind of raw-stack-dump, like provided in DrWatson logs. I need the address pointing to the frame containing the stack contents like (possible) parameters. When doing the 'classic' way of stackwalking (using EBP-register as starting point=frame), than you will find: - Return address (at offset 0, is previous function call) - Program Counter (at offset 8) - Possible parameters passed with function (at offset 16+) But... when you use optimized code, above doesn't work most the time and MSDN suggests using the DBGHELP stuff. Also the other articles in MSDN are not diving into the raw-stack usage. Above is quite complex material, and even MSDN (including technical articals) are not going that deep (except for using the classical way). Thanks in advanced, EiSl

Hello folks, I know that a service process (under NT/Win2k) should not communicate with GUI, since no user has to be logged in so no shell is available. But... When my service is crashing (unhandled exception), I want my general exception handler sends a messagebox to the user in case there's a user logged in. So... How can I detect if a shell exist (aka: a user is logged in), so I can safely shoot a messagebox. Thanks, EiSl

Hello folks, I'm currently working on my own Unhandled Exception Handler in order to provide me more information regarding the crash occurred and make a 'grateful' crash ;) . When checking the DGBHELP-library (MSDN) it also provides " User-mode Minidump Files" (crash dumps), that can be loaded within a debugger (like WinDBG). Now my questions: 1. Very little info is provided in MSDN about these MiniDumps: what exactly do they dump and how to use it (is it usefull)? 2. MSDN states: "You can use this function on versions of Windows prior to Whistler without redistributing DbgHelp.dll. To do so, link with the static library MiniDump.lib, which is included in the Platform SDK." No way I can find the Minidump.lib in the latest SDK, or more information about this. What about this library? Any info about this MiniDump is highly appreciated! Thanks, EiSl

Hello fellow programmers, I was wondering how a program like Dr.Watson is hooked into the exception handling mechanism. This question actually has a background: For my next project, they've asked me to do some bug-hunting in a HUGE (multi threaded) service process (netto > 1 mil. lines of code over 10.000 files). This peace of code (telecommunication related) has been ported from embedded system, and NO active usage of structured exception handling is used (more C than C++ oriented). The problem is that in some situations an exception occures, and we want to be able to produce *any* possible kind of info. But since the Windows NT exception handling mechanism is taking over everything, no way of getting some runtime-info. And also: it is a service process, so no interface to user exists. My idea was to implement a kind of 'general exception handling' function within our application, dumping possible information to a file. Other suggestions are also welcome, or links to site/topics regarding this topic. Cheers, EiSl

One of the examples on this site explaines the usage of multiple checkboxes in one 'placeholder' In stead of checkboxes buttons should be possible to. Be care full about keeping the GUI user friendly! Give a yell if you need more help EiSl

What do you actually mean?!?! You want a 'client' be able to test if a 'server/service' exist on a service-port over UDP? UDP is a connectionless protocol, so the only way for the 'client' is to check the connection is waiting for any response on your message. I write 'client' and 'server' between brackets, since client-server in UDP environment is not really a client-server architecture. With TCP/IP you split a socket when a connection is make (by listen -> accept), UDP doesn't do this, but you can use recvfrom to collect the others ip-address+port. EiSl

Hello all... I'm lost... maybe because I'm searching to deep, but anyway. My collega came to me for help, but unfortunately.. :confused: Let's take a look to this sample:

class CMySystems{
// Anything
};

class CMyDetails{
// Anything
};

void xxx::SomeMethod( void )
{
...
// Sets up the (docking) TabControlBar
m_wndMyCtrlBar.AddView("Systems", RUNTIME_CLASS(CMySystems));
m_wndMyCtrlBar.AddView("Details", RUNTIME_CLASS(CMyDetails));
...
}

Now the problem: In the class CMySystems I want to be able to use methods from the class CMyDetails. How can I at runtime pass the 'this' pointer of the CMyDetails class to the CMySystems? Thanks in advance, EiSl

You don't want to know this ;-) RTFM stand for: Read The Fucking Manual. Cheers, EiSl

Thanks for your answer! Most the time you read answer like: "better do this way" without a clear explaination why to do so. I've never thougth about the combination of CFormView with ListBox, because I was only looking to derivation of the View. Since it only accepts xxxView I was thinking about the ClistView or CEditView and have chosen for the editview. When everything is working fine I will take a look for changing that part, since it's quite easy to change. Happy programming! Eize

Hello John, Does this really matters?!? Ok in case of a CFormView yes it matters. In my case we're talking about a read-only CEditView, but maybe this is changed to a CListView. Sincerly, EiSl

Hello John, Thanks for reply!! This is already how it's working now. When a new document is created (OnNewDocument), a communication thread (WinThread) is started, which is using CAsyncSockets for communications. When data has to be printed, it is passed to the document. But... When I've have more than 3 documents active, and they generating quite a lot data, the main app starts become less responsive since all the documents/view updates are done under the hood of the main application thread. That was the reason for asking a thread handling doc/view archtecture. EiSl

Tomasz, Sorry I'wasn't complete :-) I've already updated the initial story. The input is not from user, but Trace Events from a TCP-socket. A separate thread (launched by the doc) forms a complete protocol handler and connects to a device. When a trace-event is received, a string passed to the doc which updates the view. It's also possible for the user to select a line in the view, and than press a button to add some comments. But this is rarely used, so: no user input to view. Hopes this completes the story, EiSl

Hello, I've got those file locally. (psapi.h,*.lib and .dll, total 27kB). It's way smaller than 80MB :-) If you provide me an e-mail address for sending it to you, I will sent it. EiSl

Hello guru's I've a interessting problem, and probably the most will say: please don't do that because of the extra headache :-D OK.. Because the fact I've a MDI application on which each doc/view can expect a lot of input. This input is no user input, but trace events read from TCP-socket. The communication handling for TCP/IP is already done it it's own thread, only passing data to the document when there's something to write. Also: I've a fast way of writing to the view, but some times the main application is very very slow in responding (moving/menu/toolbar etc) when more than 3 documents are handled with a lot of data. The problem is that all the doc/view handling is done under the hood of the applications main thread. This is the reason for wanting each doc/view in it's own thread. Now I've read sometime somewhere that someone had put each doc/view in its own thread. The question is: how to do this for a MDI application :confused: This is maybe also a very good article to store in CodeProject library. Thanks in advance.. EiSl

Hello all, Please take a look to one of the submitted code snippets, where the layout is recalculated: Link to sample in CodeProject: http://www.codeproject.com/docking/sizing\_tabctl.asp Part of the code: void CMainFrame::RecalcLayout(BOOL bNotify) { CMDIFrameWnd::RecalcLayout(bNotify); CMDIFrameWnd::RecalcLayout(bNotify); } Question: Why does the author calls the same RecalcLayout twice ?!?! Thanks, EiSl

Hello guru's, I've the feeling it's so simple, but I cannot manage it: :confused: We all know the standard menu in a MDI application made by MFC-wizard. But what I need now is having also the menu in each doc/view. I've tried some idea's, but they all failed. I succeeded in putting a toolbar and status bar, but the menu...arrghhhh!!! X| Do you have any idea's? Thanks in advance, EiSl

Hello Jake, I suppose you've created a MDI application using the VC++ Wizard. In this case, the creation of the first initial document is performed by ProcessShellCommand(cmdInfo) in the main of your program. If you check the docs, you will find that next code: ---- // Parse command line for standard shell commands, DDE, file open CCommandLineInfo cmdInfo; ParseCommandLine(cmdInfo); // Dispatch commands specified on the command line if (!ProcessShellCommand(cmdInfo)) return FALSE; --- will handle the passed arguments when you execute the application. You can override these by writing your own command-line parsing stuff. The default behaviour of ProcessShellCommand is when not passing parameters with your application: "Start appl. and open new document". Hopes this helps, EiSl

Thanks for your reaction :rolleyes: ! Just a summary of what you suggested: 1. First get access to complete memory block in CEdit 2. Do the loop-stuff as you suggested (outside the scope of CEdit) Probably by using memmove 3. Give this block of memory back to CEdit Now a little question... :confused: Let's say we're talking about 1000 lines of average 50 characters in width. What do you know about your method that it's probably faster than the 'select-and-replace-with-nothing' method? Curious about your answer, EiSl

Hello all, I've got a CEdit (read-only) in which continuously lines are added at the end (debugging stuff). Of course... if I do nothing, its memory usage will grow and grow (64k Max for Win9x, 'unlimitted' for WinNT/2k). What I want to do is to delete the first line when it passed a predefined maximum amount of lines. But... CEdit doesn't implement a 'delete-line' method. The only way I've found out was: -First select the line(s), than replace the selection with nothing. This sounds CPU-consuming to me... Does anyone knows an efficient way to do this? Thanks in advanced, EiSl