As those who've ever "converted" an EasyGauge project to a multi-gauge knows, one of the problems I (and everyone else) have encountered when trying to use the GaugeStopSound function in MSVC++ is that -well- the darn sound won't stop!I spent most of today trying to find out why the function works when compiled with MinGW (a la EasyGauge) but will NOT work when the same gauge is compiled by any other means (Borland, MSVC++ .NET 2003, et cetera)...While I still don't know why an LPTSTR "string" isn't being passed by the function, but after several hours of study and frustration, it finally occured to me to try passing an integer instead... Well I'll be darned... it works!First, I changed the "Sound declarations" as follows:// Sound declarationstypedef VOID (*TGaugePlaySound)(LPTSTR,int,int); // 2nd param changed from LPTSTR to inttypedef VOID (*TGaugeStopSound)(int); // param changed from LPTSTR to intTGaugePlaySound GaugePlaySound;TGaugeStopSound GaugeStopSound;HMODULE MGaugeSound;Then, I substituted an integer value in the function call like this: if ( *rotarytest == 1 ) { (GaugePlaySound)("soundesdgfire.wav",4,1) ; } else { (GaugeStopSound)(4); }Granted, the integer 4 isn't nearly as descriptive as -say - "firetest" but at least the bloody thing works now! ;)

Hi BillI *promise* I'll have the DirectSound/Xact gauge programming info in the next version of sd2gau. Oddly enough, I'm having the reverse problem at the moment in that I can pass integers around no problem, but FS won't play ball with a string...-Dai

The GaugeSound.dll I use was supplied with EasyGauge. I don't know who programmed the library originally, and haven't a clue what it does internally. The only clues available are the "goesinta" stuff and the fact that the "comesouta" either works or not... :( Marcel & his brother programmed EasyGauge to make use of GaugeSound.dll (which uses DirectX btw), but have since disappeared from public view. In fact, neither of them will even respond to email any longer... :(What is clear though is that obviously MinGW's compiler, include.h files and libraries do support LPTSTR differently than any other compiler (Borland and MS are the only one's I've tried). Since I have a TON of "legacy C/C++ code" to maintain, I have been struggling to find a workaround for this one issue of not being able to "stop" a specific "sound loop." At any given time, I might have ten (or more) sound loops running, so this GaugeStopSound function was critical!Not understanding and quite honestly lacking the background to determine the exact, proximate cause of the problem, I am at least satisfied now to have found a "workaround."I can at least solve the problem of identification by creating a list of #define(s) that will tie a name to the number:#define firetest 1;#define masteralarm 2;et cetera... :D

Ok... been doing some thinking on this.An LPTSTR is nothing but a LongPointerToSTRing. Dat's it. ;)As for why it doesn't behave in MS's C/C++... I suspect it has more to do with what's actually being passed than it does the actual compiler.Since a pointer (32-bit numeric value) is being passed that points to the beginning of whatever string you're using... the other compilers may be reusing memory more (or less) efficiently than the MS compiler. This resulting in the exact same memory pointer being used each time you pass the string pointer.However, it appears in the MS compiler that pointer's value is pointing to a different memory location when you go to call the sound's stop function. Thus it doesn't locate a "match" and doesn't stop the sound.By switching to physical numerical values that are 32-bit in length (int)... you're passing a unique "ID" for both function calls.Just a thought. :)

It is odd that the first LPTSTR (pathfilename) is passed to the module with no problems......it's only the second LPTSTR (stop_flag) that's somehow getting clobbered...Ah well, at least the "kludge workaround" works... flawlessly! ;)

Bill,Did this workaround not work for you?http://forums.avsim.net/dcboard.php?az=sho..._id=32505&page=Doug

>Bill,>>Did this workaround not work for you?>http://forums.avsim.net/dcboard.php?az=sho..._id=32505&page=Unfortunately, it did not do a thing......otherwise I wouldn't have spent an entire day looking for a workaround that -well- works! ;)From what I've read though, string pooling is just what I would NOT want to do:"String pooling allows what were intended as multiple pointers to multiple buffers to be as multiple pointers to a single buffer. In the following code, s and t are initialized with the same string. String pooling causes them to point to the same memory."http://msdn.microsoft.com/en-us/library/s0s0asdt(VS.80).aspxThis implies that every time I created a new "stop_flag" it would use the same buffer and overwrite my previous "stop_flag"No, wait! It wouldn't matter because I only need the buffer to hold the "stop_flag" string long enough to pass it to the GaugeSound.dll module...Man, I've got a headache!

I've come late to this thread but if UNICODE support is enabled (generally via a #define statement or a compiler option), LPTSTR is a 32-bit pointer to a null-terminated string of 16-bit UNICODE characters (wchar*). If UNICODE support is not enabled, LPTSTR is a 32-bit pointer to a null-terminated string of 8-bit Windows (ANSI) characters (char*).Could this be the source of your problem which would seem to be compiler dependent?

>I've come late to this thread but if UNICODE support is>enabled (generally via a #define statement or a compiler>option), LPTSTR is a 32-bit pointer to a null-terminated>string of 16-bit UNICODE characters (wchar*).>>If UNICODE support is not enabled, LPTSTR is a 32-bit pointer>to a null-terminated string of 8-bit Windows (ANSI) characters>(char*).>>Could this be the source of your problem which would seem to>be compiler dependent?That is quite probably the issue. If I enable UNICODE support though, the project won't compile at all.I have however, found a much safer way to solve the problem, thanks to a suggestion from Dave Nunyez, a fellow programmer.First of all, I changed the parameter to an LPSTR, then in the header create unique LPSTR named pointers:// Sound declarationstypedef VOID (*TGaugePlaySound)(LPTSTR,LPSTR,int);typedef VOID (*TGaugeStopSound)(LPSTR);typedef VOID (*TTerminateSounds)();LPSTR flap = "flap";LPSTR gearhorn = "gearhorn";LPSTR overspeed = "overspeed";LPSTR firetest = "firetest";LPSTR geartest = "geartest";LPSTR speedtest = "speedtest";LPSTR warning = "warning";Then in the mouce callback function calls to GaugeSound.dll, I use these named pointers:if ( *rotartest == 2 ){ (GaugePlaySound)("soundesdggearhorn.wav",geartest,1) ; }else { (GaugeStopSound)(geartest); }

>if ( *rotartest == 2 ) >{ (GaugePlaySound)("soundesdggearhorn.wav",geartest,1) ; }>>else { (GaugeStopSound)(geartest); } >But that code will always repeat. As long as rotartest==2 it will always call the GaugePlaySound function. Technically that's not making a sound loop at all.To make a sound loop you'd need something like this:bool sound_on = false;void start_sound(){ (GaugePlaySound)("soundesdggearhorn.wav",geartest,1);}void stop_sound(){ (GaugeStopSound)(geartest);}if (*rotartest==2){ if (!sound_on) { start_sound(); sound_on = true; }}else{ if (sound_on) { stop_sound(); sound_on = false; }}

Let me add, it's not that you aren't making it loop. You are. But you're also repeatedly telling the GaugeSound DLL to fire up that wav. Much like the keyboard repeat "issue" that exists in some gauges.

>Let me add, it's not that you aren't making it loop. You>are. But you're also repeatedly telling the GaugeSound DLL to>fire up that wav. Much like the keyboard repeat "issue" that>exists in some gauges.Actually, being contained within a mouse callback, I would assume the call to GaugeSound.dll to be a single-shot event.Also, the third param passed determines whether GaugeSound.dll plays the .wav one time or loops the file endlessly...0 = one-shot1 = loop

True, except no one reading this thread sees it in a mouse callback. ;)

>True, except no one reading this thread sees it in a mouse>callback. ;)Ah, good point. I only said "in the callback." I should have been more explicit... ;)