You'd have thought after years of creating gauges I'd know the answer to this one, but some seven-eight hours of frustration later...

 

I have a really simple standalone gauge that has seven sequential bitmaps in it, illustrating a selector switch. The gauge does nothing except rotate the switch as it's for a new section in sd2gau on using SimConnect as a gauge. Only. it. just. will. not. show. up. on. screen.

 

Would someone be willing to make me feel really stupid and take a look at the code please? :smile:

LOL

 

I can look at the code...

Hello Ed

 

Thank you :smile: Dropbox link here:

 

https://www.dropbox.com/s/eegyc6iwsgu6k1l/SelectorNoSimconnect.rar?dl=0

 

If you'd be kind enough to keep your comments public in this thread, it may help anyone who commits the same mistake. The project is currently at VS2005 because I had wondered if creating it in VS2013 was part of the problem. Any version of VS will do as I have access to all of them as part of my job.

 

-Dai

Ok... maybe I'm dense... but I don't see an .rc file. I DO see it in the .vcproj but that's it. I don't see where you've defined SELECTOR_OFF's value either.

No, that's me trying to cut the code down to as small as possible for the archive. Try this:

 

https://www.dropbox.com/s/6siidcp9nidk17u/SelectorSimconnect.rar?dl=0

 

Now a VS2013 project. SELECTOR_OFF (and it's siblings) should be in the sdk.h file?

Your bitmaps are 24-bit... don't recall anything larger than 8-bit being supported.

 

Also, you're using ICON_SWITCH_TYPE_SET_CUR_ICON and I'm not certain that will do visually what you expect it to do. I know that ICON_SWITCH_STEP_TO will step through (animate)... however I have never tried to use ICON_SWITCH_TYPE_SET_CUR_ICON and thus am not certain it even works or not. LOL

I would have thought that if ICON_SWITCH_STEP_TO was the problem, the static background bitmap (SELECTOR_OFF) would have shown up anyway. I'll give it a try in the morning and report back :smile:

 

Oh - and I'll revert the bitmaps to 8-bit where they started. Going to 24-bit was just part of the testing (or fishing around, as it would be better stated).

Well, this is a headbanger and no mistake. I threw all the code away, reduced the bitmaps to 8-bit and started again. I added a separate bitmap for the static background (a bright red rectangle) and as suggested, used ICON_SWITCH_STEP_TO.

 

FSX still requested to trust the gauge but again, nothing showed up on screen. Just so I could attach the debugger, I added this to the gauge callback:

 

MODULE_VAR tick18 = { TICK18 };

//-------------------

case    PANEL_SERVICE_PRE_UPDATE:
    lookup_var(&tick18);
break;

 

The breakpoint (lookup_var) is never hit, suggesting that the gauge is actually not loading correctly.

 

Figuring that it might be something in the compiler settings I ripped everything out from an existing working project and used the .cpp, .h and .rc files you have. Same result...

I think I know what it is... give me a minute or two...

Ok... think I got it.

 

Configuration Properties
	C/C++
		Code Generation
			Runtime Library
				Multi-threaded Debug (/MTd)
				vs
				Multi-threaded Debug DLL (/MDd)

You have Multi-threaded Debug DLL (/MDd) selected for Code Generation. This can add dependencies that may or may not be present at runtime. I've found it's 'best practice' to use Multi-threaded Debug (/MTd) to avoid potential issues.

 

As example: I see that the gauge DLL requires msvcr80d.dll when I compile it as a Debug DLL instead of as a Debug.

That might have been part of it but not all of it :mad: . I finally got round to attaching procmon to the process and found that the gauge is being loaded and then immediately unloaded. One step forward (I think....). I'll keep working on it.

A load then unload would also indicate a dependency issue.

 

Aside from that, it loads and functions correctly on my system.

Thanks Ed - time to nuke FSX. If it loads and runs for you then there has to be something fundamentaly wrong with my setup. One of Doug Dowson's gauges won't load either, but I'm sure it used to.

 

I'll get back in a few days when I've had time to press the big red button.

Dai,

I think Ed is right on this one.  Attaching the VS debugger to FSX, I noted the same behaviour you describe - with the compiled dll in the archive you posted.

I see that it is dependent on msvcr120d.dll, a file that wasn't on my system.  installed the VS2013 runtimes and that didn't change the behaviour.  When I simply recompiled the gauge with VS2012, using /MTd, the problem went away and the gauge loaded fine.

 

Which of my gauges is giving you trouble?

Hi Doug

 

It was the fuel dump gauge. I didn't push the investigation too far on that one; all I saw was simconnect connecting to it and then immediately disconnecting. I just assumed it was part of the same problem.

 

However, I think you may have saved me some time (I'll find out soon enough!). I'm going to rebuild my gauge using VS2010 with the /MTd parameter.

 

[Edit] Well, that was it :Whew:- VS2013 was causing the trouble but I have no idea why. I just built the gauge in VS2010 and it worked first time, then upgraded the project to VS2013 and it still worked. Over time I have also upgraded a major project from VS2008 through VS2010 to VS2013 and it hasn't given any trouble. I can only assume because the .vcxproj file contained the 'correct' information. Lesson learned.

 

-Dai