Creating FSX Modules??

[Manuel Ambulo]

Hi,

Just wanted to know if anybody had been working in creating a FSX module file (.DLL)..just wanted to know if the normal method for create a module (as it was in previous versions like FS2004)..still works with FSX?....(i mean it is just necessary to update the version number, 0x1000 (FSX) instead of 0x0900 (FS9)...in the version field...or all is all totally different in FSX?...the linking system is different?...:confused:

Best Regards,

Manuel Ambulo

NOTE: (Sorry by my bad english...)

[scruffyduck]

Hi Manuel

I don't know the answer to that :o Pete Dowson has clearly done it with FSUIPC4.

I have not built modules in the past but only external programs.

Hopefully someone can answer :)

[MachTwo]

Hi Manuel,

The SDK contains examples showing how to add a manu/sub menus to FSX using SimConnect. It’s a little easier than before :)

[Manuel Ambulo]

Thanks, MachTwo and also thanks scruffyduck, didnt knew that the SDKs also comes with samples to add menus. And yes, when creating modules for FS2004 it was a little bit more tricky to add a menu entry, it was to be done a lot of things before....and now things are more easier...:eek: ....its nice to now that :)

Best Regards,

Manuel Ambulo

[Pete Dowson]

... when creating modules for FS2004 it was a little bit more tricky to add a menu entry, it was to be done a lot of things before....and now things are more easier...:eek: ....its nice to now that :)


So are you okay with making FSX modules now?

There's no "Linkage" or "ImportTable". All that stuff has gone. FSX's own modules use standard exports and imports now. It's a bit annoying as it makes them messier to hook (but not impossible of course).

For an FSX-loadable DLL you need only to put details in the DLL.XML file, as described in the SDK, then, for SimConnect you need to export, as C procedures (not mangled C++ ones), a "DLLstart" and a "DLLstop". These are your replacements for the old Initi and De-Init links.

Oh, you'll need a manifest too -- the Simconnect.h contains that. Using VS2005 it is easy to get that embedded in your DLL, for tidiness.

Okay?

Pete

[Manuel Ambulo]

Hi,

Ohh...so no "Linkage", neither "ImportTable" ..well thats is a big change compared to old method to hook to the FS, mm....when you mean export "C" procedures you mean to use like (for example):

extern "C" __declspec(dllexport) DLLstart();

for export the "DLLstart" and "DLLstop"..right?....(please correct me if im wrong...)

So, if there is no "Linkage", neither "ImportTable", that means i cannt access TokenVariables (just for read..variables) from my DLL (not gauge), instead then i need to use SimConnect?..(this is not problem for me), just asking, because i already had a project of a FS module for FS2002/2004...that extracts data using Token Variables and if they arent accessable in FSX, then i may need to change the code so it can use SimConnect to extract the required data...

And about the manifest, it will be included in my DLL if i just do:

#include "SimConnect.h"

?? using my VC++ 6.0?, or it needs another special thing to do? (I have the old Visual Studio 6.0)...

Thanks, Pete, (sorry by too much questions...lol..:) ),

Best Regards,

Manuel Ambulo

[Manuel Ambulo]

LoL,...I found an answer for my own question...:D ....(in the SimConnect SDK), about the DLLStart and DLLStop function...i need to create a definition file (*.def)...using Visual C++ 2005, for export those functions...

And also, now, that i had downloaded and installed Visual C++ 2005 Express Edition....i found another answer for the other question about the manifest...found that Visual C++ 2005 itself embed the manifest inside of the SimConnect.h, everytime i re-build the project....:o

But there is still a mistery or question for me...that if there are Tokens variables available in FSX, and if there is no Linking system....how they are accessed by the gauges in FSX?....as in the past thru the IMPORT_TABLE it was done that,.......i mean you specified there the ID of the PANEL.DLL FS Module and then you could import that data (from the PANEL.DLL) directly to your FS Module.....Anyway im using now SimConnect to request and set data....so im not worried about that too much........but..this is a question that will be keep in my mind for a while...like HOW DO GAUGES ACCESS TOKENS (GAUGES = *.DLLs but with another extension --> *.GAU)...IF THERE IS NO LINKING SYSTEM...:confused:...<---(Mistery for me)...lol

But anyways, thanks guys, by the help....:)

Best Regards,

Manuel Ambulo

[Pete Dowson]

... that means i cannt access TokenVariables (just for read..variables) from my DLL (not gauge), instead then i need to use SimConnect?..(this is not problem for me)


You can use the Panels interface too. Inlcude the relevant bits if Gauges.h, and export a pointer to a PANELS structure called "Panels", thus:

EXTERN_C __declspec(dllexport) PANELS *Panels;

When Simconnect loads your module it will fill that pointer in for you, and off you go ...

And about the manifest, it will be included in my DLL if i just do:

#include "SimConnect.h"

?? using my VC++ 6.0?, or it needs another special thing to do? (I have the old Visual Studio 6.0)...

I don't think so, but I don't know. I bought VS2005 before I started. I think you will need to adapt the sample manifest file that comes with the SimConnect SDK, name it as your DLL but with .manifest on the end (after the .dll), then embed it into your DLL as resource type 2 using the manifest tool (MT.EXE) which you can get from the Microsoft site. I've a feeling you might have to get the entire 1Gb platform SDK to find it these days though.

Regards

Pete

[Pete Dowson]

Ah .. just noticed your second post ...


And also, now, that i had downloaded and installed Visual C++ 2005 Express Edition....i found another answer for the other question about the manifest...found that Visual C++ 2005 itself embed the manifest inside of the SimConnect.h, everytime i re-build the project....:o

Yes, that's much easier!

But there is still a mistery or question for me...that if there are Tokens variables available in FSX, and if there is no Linking system....how they are accessed by the gauges in FSX?

Gauges are a bit different in FSX I think. I don't think they are loaded by or need SimConnect, though they can use it.

Anyway, you'll find the way to use the PANELS.DLL facilities in my last message.

Regards

Pete

[Manuel Ambulo]

You can use the Panels interface too. Inlcude the relevant bits if Gauges.h, and export a pointer to a PANELS structure called "Panels", thus:

EXTERN_C __declspec(dllexport) PANELS *Panels;

When Simconnect loads your module it will fill that pointer in for you, and off you go ...

Wow, i didnt knew that (very interesting)...that..Tokens Variables can be accessed by normal DLLs (not only gauges)......because (before posting here...), i took a brief look at the FSX Panels SDK and there is a C++ project sample (of a gauge) that seems like to be the same C++ code sample used in the FS2004 Panels SDK....and in the updated Gauges.h file, they seems they still use the old linking system....so that kept me thinking...until now....lol :) (Thanks)


Gauges are a bit different in FSX I think. I don't think they are loaded by or need SimConnect, though they can use it.

Anyway, you'll find the way to use the PANELS.DLL facilities in my last message

Yes, FSX's Gauges a bit different from those used in FS2004..maybe because the old linking system was used for so long....we were like use to see the same system (version after version) then suddenly (not instantly,... but is like something new...never seen before) it changed...... :o

THANKS,

Best Regards,

Manuel Ambulo

[Manuel Ambulo]

So, then for create a single module compatible with FS8, FS9 and FSX, i have to export all these functions at same time:

ImportTable (used by previous FSs)
LinkAge (used by previous FSs)
DLLStart (used by FSX)
DLLStop (used by FSX)
Panels (Panels interface in FSX)

Best Regards,

Manuel Ambulo

[karijno]

OK... thanks.... but if i use PANEL *Panels when i try to write and compile
Panels->execute_calculator_code (str, &answer, NULL, NULL);
give me an error

Thanks Karijno

[Manuel Ambulo]

But the error that you receive is after compiling?..or while running the DLL in FSX?

Best Regards,

Manuel Ambulo

[karijno]

After that i compile it....!!!!!! :) Pete help!!!!!!!!!!

[Pete Dowson]

After that i compile it....!!!!!! :) Pete help!!!!!!!!!!

You are using C or C++?

What is the error exactly?

If the PANELS structure is included (from the Gauges header), which I assume it must be as you have a pointer to it defined as Panels, and if that structure has an entry for

(*execute_calculator_code )( ...)

(does it?) then provided your parameter types match the compiler should be happy enough.

So check back. Does the PANELS definition include that function? The one I'm using doesn't. If so do they parameter types match?

The clue should be in the error you are getting. Usually the compilers are pretty good at saying what is wrong.

Incidentally trhe only calls in PANELS I've ever used are

void (FSAPI *initialize_var_by_name)( PMODULE_VAR module_var, PSTRINGZ name );
void (FSAPI *lookup_var)( PMODULE_VAR module_var );

and even "initialize" isn't used these days.

Regards

Pete

[Manuel Ambulo]

The clue should be in the error you are getting. Usually the compilers are pretty good at saying what is wrong.

Yep, Im agree with Pete, i think that the clue is in the compiler...as it is very hard to say what is wrong as many things can cause an error (i mean many possible things....even a little word mistake can produce many errors...lol...:) ), so if you may post what does exactly the compilers says...or what's the exact error, it would be (i think..or maybe)..more easy to tell what is going wrong...so we can help you better.


Does the PANELS definition include that function? The one I'm using doesn't. If so do they parameter types match?.

Yes, Pete, it is a new function added to the PANELS structure in the new updated "gauges.h" of the FSX...the function looks like this in the PANELS structure:

BOOL (FSAPI *execute_calculator_code) (PCSTRINGZ code, FLOAT64* fvalue, SINT32* ivalue, PCSTRINGZ* svalue);


Incidentally trhe only calls in PANELS I've ever used are

void (FSAPI *initialize_var_by_name)( PMODULE_VAR module_var, PSTRINGZ name );
void (FSAPI *lookup_var)( PMODULE_VAR module_var );

Me too, from the PANELS structure (in FS8 and FS9)..i used to use more those two functions (to access Tokens)...i never had used the others..:(


I also have a little question....in the FSLINKAGE part (at the beginning of the PANELS structure, you set the version of the FS to 0x1000 right? (FSX) <---that's maybe a stupid question (sorry..lol)...but just to be sure if i have to put 0x1000 or can i also leave it as 0x0900 (FS9)?..or it is not needed to set the version of FS?...and....the pointers to:

void (FSAPI *ModuleInit)(void); \
void (FSAPI *ModuleDeinit)(void); \

I need to leave them as NULL both?..as you know that there is no linkage...and those functions were replaced by the new DLLStart and DLLStop.

(Sorry by asking those basics questions), :o

Best Regards,

Manuel Ambulo

[Pete Dowson]

I also have a little question....in the FSLINKAGE part (at the beginning of the PANELS structure, you set the version of the FS ... or it is not needed to set the version of FS?

None of that part of the PANELS structure is used for a SimConnect client. I wouldn't write to any of it at all if I were you. Don't forget that the data that Panels points to isn't in your module in any case, it's something SimConnect had derived for you. It may even be common to all SimConnect clients.

The PANELS pointer is filled in by SimConnect when your DLL is loaded just so you can access the procedures in the structure. All that other stuff is to do with the old pre-FSX methods of loading and initialising/ending modules which doesn't apply now.

They may still be used in the Gauges side of things. I don't know whether there have been changes there or not. Simconnect doesn't load those.

Regards

Pete

[Manuel Ambulo]

Thanks, Pete, i was forgetting that the PANELS pointer is pointing to somewhere OUTSIDE of my module and writting on it (example: in the FSLINKAGE part or somewhere else in the structure)...may crash the FS or do something unexpected...so i will just export it and like i say: "dont touch it" (write or read on it)...until my module got fully loaded by SimConnect. So then, after loading, i can use the "initialize_var" and "lookup_var" functions for access and read the tokens. :)

Hey, karijno, did you solved the compiler's problem?...(i mean did you found the solution for the error?)...:confused:

Best Regards,

Manuel Ambulo

[karijno]

Hi Manuel and Pete,

sorry but i was out of city for that period . I always have the same problem.
When i try to compile my code , VS tell me that i have mismatch a "(" bracket in my method call i explain :

i have declare a (....PANEL * pan) external in gauges.h
in my .cpp file i included gauges.h
in my code i used in this way:
- pan->execute_code_calculator("blablabalbalb", &answer, NULL, NULL);

at this point compiler tell me that i have mismatch a "(" bracket .

Have any ideas?!?!?

Thanks a lot

Fabio

[Pete Dowson]

VS tell me that i have mismatch a "(" bracket in my method call i explain :

i have declare a (....PANEL * pan) external in gauges.h
in my .cpp file i included gauges.h
in my code i used in this way:
- pan->execute_code_calculator("blablabalbalb", &answer, NULL, NULL);

at this point compiler tell me that i have mismatch a "(" bracket .


First, note that the PANELS * export must be named "Panels" otherwise SimConnect will not find it and fill it in. "Pan" isn't right.

Second, there must be an error some place in the definition of the PANELS structure, so let's see the definition of your PANELS * and the PANELS structure itself.

Regards

Pete

[karijno]

i ve used also " Panels" but bracket error remains!!!! i use gauges.h WITHOUT mod....

Ciao
Karijno

[Pete Dowson]

i ve used also " Panels" but bracket error remains!!!!

I was not saying changing the name fixes the compilation error, but just that if you don't use the name "Panels" then Simconnect won't find it and fill it is, so if you ever did get to compile and run your program it would crash there with a zero pointer!

i use gauges.h WITHOUT mod....

What, the one from FS2004 or the one in the Panels SDK from the Deluxe edition SDKs? Let me check. I've always used my own without all the stuff I don't use (I have never made gauges).

....

Okay. I have looked in that, and I cannot see any sign of a procedure called "execute_code_calculator". The only one similar in the PANELS structure is:

BOOL (FSAPI *execute_calculator_code) (PCSTRINGZ code, FLOAT64* fvalue, SINT32* ivalue, PCSTRINGZ* svalue);

Are you sure you are not simply trying to use an incorrectly named entry?

Regards

Pete

[Manuel Ambulo]

Originally Posted by Pete Dowson:
I was not saying changing the name fixes the compilation error, but just that if you don't use the name "Panels" then Simconnect won't find it and fill it is, so if you ever did get to compile and run your program it would crash there with a zero pointer!

Yes, that is true......karijno, you have to name it as "Panels", because after SimConnect load your module, will look for a pointer called "Panels", if it doesnt finds it, it will not fill that pointer, as result, it will remain as a NULL pointer, causing a possible crash if you try call it.

At this point, i may suggest you, karijno, to do a cross-check after your module is loaded by SimConnect, to do a: "if (Panels == NULL)", then display some kind of warnning or something like that so you can see (during your tests), when the pointer had been filled or not, before calling any function from it...And also check that you are calling the correct name entry, as Pete, said, if you call an incorrect function entry, it will not recognize it....:)

Best Regards,

Manuel Ambulo

[ziporama]

I thought I followed instructions (for a change :)) but had absolutely no luck with getting SimConnect to populate the Panels pointer - until I discovered the problem.

YOU MUST HAVE A DEFINITION FILE (.DEF) ATTACHED TO YOUR PROJECT OR *Panels DOESN'T POPULATE.

The catch is that a module definition file is technically not needed (per VS2005 docs) as the "inherent" export happens simply because of the __declspec(dllexport) keyword is present. That works fine for functions apparently, but not for variables.

The solution is to add a definition file to the project and not rely on the automatic export of symbols.


A basic FSX module dll in C++ looks like this:



// EXTERN_C normally defined in winnt.h
//
//#ifdef __cplusplus
// #define EXTERN_C extern "C"
//#else
// #define EXTERN_C extern
//#endif

// FSX module template

#include "gauges.h"

EXTERN_C __declspec(dllexport) PANELS *Panels;

EXTERN_C __declspec(dllexport) int DLLStart()
{
// called by SimConnect when dll is loaded
return 0; // return 0 for S_OK or load is cancelled
}

EXTERN_C __declspec(dllexport) int DLLStop()
{
// called by SimConnect when dll is unloaded
return 0;
}

// dll entry point - not called by SimConnect - this is called direct when the library is loaded by the O/S
EXTERN_C BOOL WINAPI DllMain(HINSTANCE hInstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason) {
case DLL_PROCESS_ATTACH:
//good place to hook the main window handle if needed using FindWindow("FS98MAIN", NULL);
break;

case DLL_PROCESS_DETACH:
break;

}

return TRUE;
}



The module definition (.def) file for the above is here:



LIBRARY "your_module_name_goes_here"
EXPORTS
DLLStart
DLLStop
Panels


The *Panels pointer is populated by the time DLLStart() is called so the functions it references (including execute_calculator_code) can be used during or after DLLStart() executes.

Another thing to note is the function names are case sensitive, and DLLStart() works, where DllStart() does not...

Cheers,

Etienne

[Pete Dowson]

YOU MUST HAVE A DEFINITION FILE (.DEF) ATTACHED TO YOUR PROJECT OR *Panels DOESN'T POPULATE.

Well, odd that then. I've never made any .DEF file, just using:

EXTERN_C __declspec(dllexport) PANELS *Panels;

in my code, and it always populates correctly. I am using VS2005. Maybe there's something else in the project properties doing it?

Regards

Pete

[ziporama]

Well, odd that then.

What can I say Pete! It seems that oddities are the rule in the FS world :)

I'm thinking perhaps a default behavior difference between the C and C++ compilers/linkers and how the manifest ends up in the dll. Clearly something different in the linking process. It may also has to do with how Simconnect looks up the entry points.

One thing for sure in my case - removing the def file, even while compiling and running just fine, leaves *Panel to a null pointer, and has no errors.

The Simconnect doc does indicate a DEF file is needed, which I admittedly ignored completely. I'm running VS2005 SP1 if that makes a difference as well.

Regards,

Etienne