C / C++ / MFC

Fine to heat that you got some kind of success. To post a link just copy it to the clipboard, insert in the CP editor, and wait a short time. It will be inserted as link with the title of the page as pre-selected link text (so it can be edited).

It is difficult to answer without knowing how the data are used. But a short web reserach found this: [EIGEN] How to get in and out data from Eigen matrix | Vlad's Blog[^]. So it seems that you can use Map to get a pointer to the complex values. That should be sufficient because the real part is stored first and therefore already at the specified index (when *p is a pointer to a complex array, p[n] and p[n].real() have the same address).

If it clears things up at all.... If you ever write some C++ code using MFC (Microsoft's Foundation Class, essentially an OO wrapper around the WinAPI), you'll notice that there are always initialization routines aside from constructors (they're called OnInit...blah ). If you happen to use a dialog object, and attempt to draw from the constructor instead of the initialization routine, you'll notice that the objects exist but are not windows yet so you'll get an assertion (if running in debug mode). This means that the constructors have been called but nothing has been drawn yet. The drawing only occurs after all the constructors have been called, the initialization routines are systematically called after that and you can load all the widgets with whatever the default values to be displayed are. Moral of the story, drawing typically doesn't take place during construction of objects.

I would think that in general, mutexes are purely kernel controlled objects whereas critical sections are mostly "user mode primitives", meaning it's application level logic most of the time (which runs a lot faster without requiring the kernel to be involved). Of course, this also implies a critical section is bound within a process and cannot be shared across processes. The exception is when there actually is a conflict, then a critical section makes a kernel call for synchronization. If you write some test code, you should be able to notice the speed advantage of a critical section (and all the kernel system calls of a mutex).

Example of what? If you want to use a printer driver then Google will find you one. If you want to write it yourself then Google will again find you samples.

So when you set a breakpoint at the for loop after pos = lstItems.GetHeadPosition(); that is not hit and execution is not stopped? That would be weird. I assume that you are using a debug build with all optimisations disabled. Otherwise, the compiler may optimise away the following lines because they effectively do nothing. To check this you can insert a TRACE statement inside the loop printing nElement.

Set tie.iImage to -1 and make sure SubjectTab is a valid tab control HWND.

Hey there !! LOOK OUT - LOOK OUT - LOOK OUT - LOOK OUT - :~ The problem is NOT on the dbZero - but on the dbInf. :confused: That explains everything you see. dbInf is 1 divided by zero, which is undefined. Anytime you try to use this value, you´ll have problems. That´s why you CAN print dbZero, but not dbInf or (dbZero * dbInf). Ok ?

Super. I've probably got operator functions around that work because of this, I've just never noticed or thought about it before.

I've had to do this many times, and have found the easiest way is to use (global) named pipes. The process that does the word opens the pipe server, and just waits for a message to come through. Any processes that need an action to be preformed then open a client pipe, and sends all the data through. This system even allows for duplex messaging, so the server can send a response and/or the results of the processing back to the caller if required. The Microsoft Devcenter explains it all pretty well, with examples, here[^].

Jochen was right on qeue I put a pragma for optimize off Around the code and it was able to build

Thanks.

alright I like this one :thumbsup::thumbsup:

@Jochenn Thanks, l made the corrections and it worked.

honor3us wrote: ...just needed to close the file and open again... Or call rewind(). "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

You may have a look at the SetupUninstallOEMInf function (Windows)[^]. It can be used to check if a specified INF file is installed and to remove it.

You should use your debugger to check what options are set each time you make a change, and remember to remove the ones not needed. You also need to refresh the Window after making any changes.