Start a new topic

Getting the 'flashing' flag off a lightpoint - how to do it?

Original Post by: chrisell Wed Feb 17 18:10:15 2010


I've got an interesting problem here. I'm trying to determine if a given lightpoint is flashing or not. The files are openflight 15.7 but I'm reading them with the 2.6 API


I figure it's creating a light point palette when it reads the file so I've tried


mgGetAttList(rec, fltLpAnimation, &animpalettenumber;, MG_NULL); 


to grab the animation palette ID number but it errors out, with this sort of message:

W: Unable to get attribute value 2792:"NULL" [argument number 1].


Trying to go the other way and just get the flashing flag directly from the lightpoint (as if it wasn't in a palette) I tried this:


mgGetAttList(rec, fltLpFlashing, &flashing;, MG_NULL);


That doesn't give any errors but it always returns zero (FALSE).


Confused.


Original Post by: SteveThompson Wed Feb 17 18:52:21 2010


W: Unable to get attribute value 2792:“NULL” [argument number 1].

Normally this suggests that the rec you are passing to mgGetAttList does not have the attribute you are asking for. However the "NULL" string here gives me some additional interesting info...


First, make sure rec is a fltLightPoint node (I suspect it really is but make sure)


Easy to check by

mgcode code = mgGetCode(rec);

assert(code==fltLightPoint);


If rec is really a fltLightPoint, the real problem might be that the wrong version of fltdata.dll is loading in your stand-alone environment. Back to the mysterious "NULL" string in the message... This indicates that the code 2792 is unknown (if it was known, the "NULL" string would be replaced by "fltLpAnimation") and this very much points to you having the wrong version of fltdata.dll loaded.


Verify in your stand-alone program environment that the correct version of fltdata.dll is being loaded.


As to your second method, that definitely won't work in API 2.6 but would in API 3.0. See the Release Notes (v3.0 sections - Light Point API Compatibility) for more info.

Original Post by: chrisell Wed Feb 17 19:16:19 2010


Curiously, the second method actually does work in the 2.6API. I had a bug elsewhere in my code where I was trampling on the boolean variable and it was always coming out FALSE.


So this is what I ended up with:


bool flashing = false;

mgGetAttList(rec, fltLpFlashing, &flashing;, MG_NULL);

if (switchnumber == edgelightswitch && !flashing)

{

rest of code

}


I ran a couple of tests on a model where I set up lightpoints with flashing flags and without and that above section of code weeded out only the non-flashing lights.

Original Post by: SteveThompson Thu Feb 18 22:51:07 2010


Curiously, the second method actually does work in the 2.6API. I had a bug elsewhere in my code where I was trampling on the boolean variable and it was always coming out FALSE.

That is very curious indeed because we did not add the Light Point Palette indirection code until v3.0.


Another explanation would be that your 2.6 runtime environment is really finding v3.0 or newer versions of the API DLLs at runtime. Remember just because you link with 2.6 version of the SDK link libraries, you still might be running with different versions of the Dynamic Link Libraries (DLLs). This all depends on how your stand-alone program environment is setup.


In any event, I'm glad you got past the problem - even if there may be gremlins involved :-)

Original Post by: chrisell Thu Feb 18 23:25:09 2010


The mystery deepens.

This is where I'm pulling the lib files for linking:

C:\Multigen2.6API\Multigen\lib


This is where I'm getting the .h files:

C:\Multigen2.6API\Multigen\include\openflightapi


Running 'depends' on my executable reports all the multigen DLLs have a date stamp of 14-03-2002 and they report a version number of 2.5.1.314


So now I'm doubly confused because it appears I'm linking with the 2.6 libraries but then running with 2.5.1 DLLs which surely ought not to work at all?

Original Post by: SteveThompson Fri Feb 19 00:15:25 2010


Running ‘depends’ on my executable reports all the multigen DLLs have a date stamp of 14-03-2002 and they report a version number of 2.5.1.314


So now I’m doubly confused because it appears I’m linking with the 2.6 libraries but then running with 2.5.1 DLLs which surely ought not to work at all?

This is exactly what I suspected yesterday and explains why mgGetAttList for fltLpAnimation does not work on your light point node. In the fltdata.dll v2.5.X, there is no attribute called fltLpAnimation to "get" hence the message you reported.


When you get into this situation, your app will "run" but it may not do what you think it is doing. In your particular case, your app would NOT run if you were using a function that was new in 2.6. You're exe would just not start up if any function it uses is not found in the DLLs that load. fltLpAnimation is just a number (2792) so that would not cause your exe to NOT run.

Original Post by: chrisell Fri Feb 19 00:29:46 2010


Ok but fltlpflashing is OK in the older version of the API ?

Original Post by: chrisell Fri Feb 19 00:51:45 2010


So moving on logically I figured I should try to move everything to the 3.5 API to ensure I had all my ducks in a row (so to speak).

I changed my project to use the 3.5 includes etc and it all built without issue but now when I come to run the executable, I a popup window with a Runtime Error message R6034.


This error disappears when I remove msvcr80.dll from my path, but then the app won't run because it says it needs it.


So I dug a little deeper and compiled some of the example code that ships with the 3.5 API and all those samples exhibit the same problem - they compile OK but they all give me the R6034 error popup when they try to run.


Any clues what might be causing that? We tried it in Visual Studio 2003 and 2005 with the same result (both on my app and the 3.5 sample apps).

Original Post by: SteveThompson Tue Feb 23 13:45:43 2010


When we switched from VC6 to VS2005 (API 3.4), there was an issue with the API libraries that forced you to link your app with the release version of the C-Runtime libraries. If you linked against the debug version you'd get this (or similar error). See API release notes for 3.4 (this affects 3.5 as well).


This was addressed by API 3.5.2 patch.

Again, see the release notes for more information.

Original Post by: chrisell Tue Feb 23 14:43:41 2010


We tried linking with the release versions and still got this problem. Where can I get the 3.5.2 patch? I don't see it on my dashboard and I'd like to try that and see if it cures the problem.

Original Post by: SteveThompson Tue Feb 23 15:53:35 2010


We tried linking with the release versions and still got this problem.
I suspect you might have some other plugin DLL in your environment that the API has found and is trying to load that is giving you this error. The OpenFlight API 3.4 and 3.5 (by themselves) will work as the release notes indicate. I just verified the samples distributed work ok. To try that at your site, clear out your plugin folder and re-run your app. Again, it's probably some plugin DLL you're trying to load that is linked incorrectly. MicroSoft really changed how DLLs are loaded so beware.


Contact Tech Support for the patch.

Original Post by: chrisell Tue Feb 23 16:04:20 2010


Ok we tried removing all the DLLs and plugin folders. Running the app (or the sample apps) produces DLL errors for each one that it can't find - as we expected.

So we copy each one into the local folder with the executable one at a time until all the errors are gone. This guarantees that it's trying to read exactly that DLL because our path has "./" and nothing else.

The last file it complains about is msvcr80.dll. Once that's copied in, the app runs, but them crashes with the aforementioned error. Removing that dll results in the app crashing because it can't find it.

This is the same for apps I've written and the samples supplied with the API. We've tried them on multiple machines with multiple environments and can't get even the samples to run.

Original Post by: SteveThompson Tue Feb 23 17:05:19 2010


The method you describe of moving c-runtime DLLS around to satisfy your app is so VC6 ;-). This is just not reliable anymore since MicroSoft introduced "manifests" in DLLs. i.e. there is a whole new way for apps to find DLLs at runtime. If you are going to copy msvcr80.dll around, you have to copy the "right" one that the OpenFlight API needs. If you copy the "wrong" one, its as bad as not having one all and you would see exactly the errors you report.


This would explain why (on my computer) the samples run fine. The version of msvcr80.dll found on my system is exactly the version the API DLLs were built against (my installation of VS2005 - your installation is probably different or you are otherwise finding a different version of msvcr80.dll).


Your best best is to get the 3.5.2 patch (which embeds the manifests in the API DLLs correctly). When you do that this "DLL Hell" will be easier to cope with.

Original Post by: chrisell Tue Feb 23 17:46:20 2010


I'll ping support for the patch and see what happens.

Original Post by: chrisell Fri Feb 26 19:09:35 2010


So I got the patch but according to Lars "The VC6 version does not require this patch. The patch fixed the embedded manifests in the OpenFlight DLLs for VC8 only. "


I'm seeing this problem in VC6 using Visual Studio 2003. As a side note we did also see it using VC8 with Visual Studio 2009.

Login to post a comment