One object should hold the data and the others point to it.

Hi I'm talking about this neat feature that treates your code like a tree and lets u see just the branches u want while the others are hidden behind a [+] Is there anything like that in any VC6 addin? TIA, :-)

Maybe someone called ExitProcess? put a breakpoint in ExitProcess and track back the call stack..

Of course xsl can do it, but u will have to render it into .h files in a pre-compile step. macros will take less time to write and pre-compile without a hustle.

the disk driver must be up, or else, wher did *this* driver load from???

socket closure causes 1. completion of a queued read operation with 0 bytes(gracefull close) and this is no error. or/and 2. GetQueuedCompletionStatus returns false. now GetLastError returns the error of the queued operation. U gotta mungle with the OS's settings to allow more sockets and give WSAAccept/accept a big queue.

I could think of few ways. But first I'd try to communicate with something existing: - DbgView - they have some new mode - something to do with bootup logging. - The event log service - softice Now, if u crash during logon, the machine is already up with all the services and stuff, so u can use lots of ways, it just depends on your kernel mode arsenal. Anyway, all the ways that don't include DbgView/event log/softice involves a bit of work in writing the logger service.. U could comunicate with your logger using sockets/pipes, like OutputDebugString - with shared mem and event, or, u could just log it to a file yourself.

simply put - what u throw is what u get. try/catch are not defined to give info like line numbers, only what was thrown. to get more info u'll have to use SEH, but then u lose unwind semantics...

A BHO can basically do whatever it wants :p A BHO sits in the browser app, thats outside the page, and add-ons are embedded in the page. For that reason BHOs has a wider view of things.

ODBC is just an interface - it has no engine for SQL Server.

Thats probably because of caching: The function's local stream is closed as the function exists so the file is flushed to disk and closed. On the other hand, the class member stream is not flushed so u c a file but no data. To check this u just have to flush the file explicitly. [I'd paste some code here but I use FILE*fh=fopen or CreateFile. Never c++ streams nor CFile]

Oops.. You are right! The documentation for CreateFile says that the dwFlagsAndAttributes argument is ignored on console objects.

You are wrong here. Sharing flags are supplied to answer any possible user's need in creating/opening any kind of stream(file/pipe/sock...) but nobody said you could trust the sharing flags to automatically synchronize the read/write operations. Thread synchronization is the user's responsibility and using a named mutex is very simple and generic solution. In cross-process scenario the solution must include a lock/spin on a global object so these are the options: 1. The file itself, that can be locked on opening, so the other task should spin on CreateFile till success. 2. Lock on a named mutex 3. Use some other shared info like the registry

it wont help the problem is not your fopen but the multiple process access. u can several things. here are 2: 1. lock on a mutex with a name derived from the file's name. 2. if u can't open, Sleep for 10ms and retry repeatedly if u just enable other processes to touch the file while u write it, u will very quickly garble the file btw - in my openion fopen is much better than CFile

so maybe instead of CreateFile(CON) u acquire the handle u want from GetStdHandle ?

this should be no problem if u know it's data format. I don't know what format u are reffering to, so lets assume the pixels are arranged in lines and are 4 bytes. Now u can just read the blocks in a double loop:

int bx = block_x*block_width;
int by = block_y*block_height;
for(int x=0; x<16; x++) {
for(int y=0; y<16; y++) {
int pixel = data[(y+by)*img_width+(x+bx)];
}
}

HTH, :-)

It can be done. The display properteis>screen saver property page does it. Inspecting it with spy++ tells that the screen saver (*.scr) creates its window as a (grand grand grand)child of the property page window. So just create a window in the child process and call SetParent on it with a HWND from the parent process

the completion key should not be 0. besides, i always create a iocp with no handle, and then attach stuff to it.

I dont know Inventor but what u should basically do is to call TranslateMessage and DispatchMessage for every message. For this u must have all the message params including HWND or u can run your dialog modal - run a modal loop. Here's a very basic one that can fit a openGL app:

WindowProc(...)
{
   :
}

:

// modal loop
CreateWindow(...);
for( ;; ) {
    PeekMessage(...);
    if( dialog closed )
        break;
    if( message ) {
        if( hWnd != myWnd )
            continue;
        TranslateMessage(...);
        DispatchMessage(...); // tihs will call WindowProc
    }
    else { // no message
        // idle -> render the gl window(s)
    }
}

u're right, its per implementation, I was refering to mine - VC6