Yes, 322.9 :-) -- Nitzan

You're welcome. There are separate options for each "Configuration". You can add configurations (say you want "Debug", "Release" and "Debug with statically linked MFC"), and even delete configurations so you're left with only one. You don't "have" to do anything. The only question is who is going to use your lib, and what their requirements will be. If it's only you, and you don't care, then provide only one (Release would probably be best, since Debug might need other debug DLLs if you've used them in your lib). One more thing you should be aware of is that VC++ has a deficiency of some sort: if you use project dependencies (for multiple DSPs in one DSW), then if your "main" project is a "Debug" build VC will take the "Debug" build from all other projects. That means you need a "Debug" build in your lib if you use projcet dependencies. BUT -- if you simply insert the name of your lib in "linker / input" then you're safe and there's no problem. -- Nitzan

Actually, in terms of MSE the average *is* the best option. It's an unfortunate example which you brings, but the general case favors the average. I can make another suggestion, if it's acceptable: plot *3* graphs: average, mix, and max. For each "pixel" plot in one color the min, in another the max, and in a 3rd color the average of the "group" of values which that pixel represents. That way you'll get a better feel, I believe. -- Nitzan

You compiled the .lib and your project with different "Run Time Libraries" option. Go to Project-Options, and under "C/C++" / "Code Generation" you'll find a combobox with options for which C run-time lib to use (Debug, Debug Multi-threaded, Debug DLL, Debug Multithreaded DLL, etc). Make sure it's the same in your lib and in your project. (Basically: if you're writing MFC them Debug Multithreaded DLL for the debug build). -- Nitzan

If it's TCP, you needn't worry. It's buffered, and if the buffer space runs out the other side will know this. If it's UDP -- it will get buffered on your side until the buffer runs out. Then new packets will get lost. If it's another protocol -- well, that's up to your protocol stack. -- Nitzan

I believe it can't, but that doesn't mean you're stuck: simply create an "empty" document class. To add the view to that document, you can either do it manually, or even better: create a document template. You can create the document using the class-wizard, which is a snap. The template you simply instanciate with the run-time classes of the document and the view. -- Nitzan

You need MinGW Runtime, MinGW Utilities, MinGW, and get binutils too 'cause its useful. There is another post in this thread which is also correct: I suppose you can simply google for "windows awk" or "windows sed" to get just these. -- Nitzan

Maybe I wasn't clear enough: you can install a small subset of the command-line utilities on Windows. They're great for everyday tasks. I recommed you go look at mingw: minimal GNU for Windows. Still, if you don't want to for some reason, my suggestion still holds: export as CSV, and use a macro of some sort in a text editor to format for MATLAB. -- Nitzan

Or at least... unix command-line tools, such as sed, awk, grep, cut, etc. I would simply export the file as CSV, and then do some simple text processing on it. I recommed you install mingw or cygwin for a quick way to get those tools. You can also get it done with macros in a decent text editor, I suppose. -- Nitzan

The difference is the fact that va_start() is a *macro*. The word "first" is literally passed to it, and it is then used. va_start() uses it's second argument by doing &MySecondArg, this is why you get the "& on constant" error (0 in your case). This is because va_start() needs to know where from the stack to read next. Since the second argument you pass to it is one of your function's arguments, taking it's address returns a place on the stack. From there, va_arg() keeps moving. The va_list is simply a pointer to the next place, and this is what gets updated every time you use va_arg(). -- Calius

All options will work for you, since all options will result with DriverFunc() being called on the correct object. The way I usually do it is option (2), actually. It's a small price to pay (1 line of code) for the generic mechanism you gain. Just in case we're not talking about the same thing when we're saying "option (2)", here's what I mean (in an all-madeup example): Let's say you have a function (or a method of some class) which needs to call some "callback" function with three parameters: an int, a double, and a char. It's customary anyways to add a "context" or "userdata" argument to such callback functions (even in plain C) so you can use the same function for several callbacks, and each of the callers will pass a different first argument ("userdata") according to what was requested when the cb func was registered. In our case we replace this "context" / "user data" with a pointer to the actual C++ instance. We define a type for the cb func: ClassMethodCbFunc -- it gets our int,double,char arguments, plus another parameter which will become the "this". ------------------------------------------------------------------------------------------- typedef int (*ClassMethodCbFunc)( void* This, int Param1, double Param2, char Param3 ); // (Note: "This" and not "this" !) ------------------------------------------------------------------------------------------- The function (or some class method) which wants to use this type looks like: ------------------------------------------------------------------------------------------- void FunctionWhichCallsMethodCb( ClassMerhodCbFunc Func, void* This ) { ... int Res = Func( This, 1, 2.0, 'c' ); ... } ------------------------------------------------------------------------------------------- ... that is: it calls it's "Func" argument with the "This" parameter it receives, and the values for Param1, Param2 and Param3 can be anything. ("Func" and "This" go together: when one is passed for a func to another, so will the other one. Just like the "CbFunc" and "userdata" in "plain" C). Now for the class which actually contains the method that will eventually be called: ------------------------------------------------------------------------------------------- class CMyClass { public: int MemthodBeingCalled( int Param1, double Param2, char Param3 ) { return Param1 + Param2 + Param3; } static int MethodBeingCalled__Wrapper( void* This, int Param1, int Param2, char Param3 ) { return

Yes. You are trying to send a MEMBER FUNCTION as a "regular" (global-scope) function to CWork::DriverFunc(). You can't send pointers to member functions as "regularly" as you send pointers to "regular" functions. The discussion on this is long, and you would have no problems finding the reasons on the web. It's too long to be included here. In any case, you have three basic options: 1) If you don't care that DriverFunc() will get a CWork-method (rather than "any" function returning double and accepting a double-array), you can change it's prototype to: typedef double (*CWork::dblfunc)(double[]); double CWork::DriverFunc( dblfunc func, double start[] ) { ... } 2) Instead of passing "Equation" to DriverFunc, pass an intermediate function which will call Equation. This function will be a static member of CWork, so even if Equation() is "hidden" it will still be able to call it. This also means you'll have to pass "this". Here's how it goes: static CWork::CallEquation( CWork* That, RestOfParamsForEquation ) { That->Equation( RestOfParamsForEquation ); } and then: typedef double (*WrapperForEquation)( CWork* That, RestOfParamsForEquation ); CWork::DriverFunc( WrapperForEquation w, double start[] ) { ... ( Whever you want to call the passed function, use w(this,ParamsYouWouldLikeToPass) ) } And then in WorkIt(), call DriverFunc with CallEquation() as the first argument 3) The third option is THE ugliest by far, slightly more complex, but does EXACTLY what you want. It will only work if Equation() satisfies a list of requirements (non-virtual, non-static), is NOT portable, and like I said: ugly. But it actual usage it's the simplest, and I like it... The idea is basically to circumnavigate the compiler's type checking system (which is what yells at you in the first place), which WILL allow you get the address of CWork::Equation. You would have to use the value with care, but it can be done. I'll elaborate more if you want, but like I said: it's ugly... Good luck. -- Calius