Sign in to follow this  
Guest bartels

2 different gdi+ gauges at the same time

Recommended Posts

Hi, Has anyone had any great success with running two different gdi+ gauges at the same time? If so where and how often did you put the gdi+ startup and shutdown gauges. Arne is already on this one but I wanted to see if other people had any opinions.ThanksJon

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hey Jon.Yes, Ettiene and I are building two gauges at the same time, the PFD and the MFD. Each is a separate gauge file, and both have the startup of GDI+ in CONNECT_TO_WINDOW and the shutdown in DISCONNECT.They work fine for us, and you can go to our forum to spy on them if you'd like, I posted some pics a little bit ago.

Share this post


Link to post
Share on other sites

If you want to put two GDI+ gauges into the same gauge file, you have to call the startup and shutdown functions only once. The best place is the callback function of the *first* GDI+ gauge in your file. Use CONNECT_TO_WINDOW and DISCONNECT, just as Fabio said above.EDIT: There's no problem when the GdiPlusShutdown() function is called in the first GDI+ gauge because all other gauge are in the DISCONNECT phase too at that time and won't try to repaint themselves.

Share this post


Link to post
Share on other sites

Linkage table have links to module_init() and module_deinit() functionsSo I put startup and shutdown calls to these functions and all works fine without concerning how many gauges there and which is first

Share this post


Link to post
Share on other sites

Hans,I did exactly what you said in my intial attempt but got no luck. Any other ideas?ThanksJon

Share this post


Link to post
Share on other sites

i have seen these functions in the gauges.h file but im not sure where to put them although Im guessing just by the name that they are called in similar fashion to panel connect and disconnect. Perhaps you can shed some light on this for me.

Share this post


Link to post
Share on other sites

Look:#define GAUGE_TABLE_BEGIN() extern GAUGEHDR gauge_header; void FSAPI module_init(void){} void FSAPI module_deinit(void){} In stock gauges.h module_init and deinit soes nothingYou are free to add something between {}Like this:void FSAPI module_init(void) {GdiplusStartup(&token, &input, NULL); } void FSAPI module_deinit(void) {GdiplusShutdown (token);} token and input are global variablesdon't forget include required headers there :)

Share this post


Link to post
Share on other sites

Jon,what exactly happened? Did the whole thing crash or did the gauge stay blank?

Share this post


Link to post
Share on other sites

after I click the "FLY NOW" button, the loading screen comes up but nothing loads. It just sits there until I force it to exit. Then it says the cause of the problem is gdiplus.dll. I didn't have this problem when it was just my one gauge though. A few other things that may affect it are that A: I have used static for just about everythingB: I placed ULONG_PTR token variable in the main .cpp file and in the gauge .cpp file with out any change.Both gauges call rendering functions instead of drawing straight from the pre draw routine. Anyway There is nothing ingenious in the code so I would be willing to show people who have an idea as to what could be wrong.ThanksJon

Share this post


Link to post
Share on other sites

This test gauge works with two GDI+ gauges in the same maingauge (they are identical, just for test). No problem on my machine (AMD 2400+ W98SE) with using both subgauges (and even one multiple times) on the same panel. The module_..init() functions aren't touched, all initializations via the gauge callback. It made no difference if a "token" variable was globally,locally or static declared, or pgauge->user_data was used for GdiplusStartup/GdiplusShutdown.Arne Bartels

Share this post


Link to post
Share on other sites

>Look:>>#define GAUGE_TABLE_BEGIN() > extern GAUGEHDR gauge_header; > void FSAPI module_init(void){} > void FSAPI module_deinit(void){} >>In stock gauges.h module_init and deinit soes nothing>You are free to add something between {}>>Like this:>>void FSAPI module_init(void) {GdiplusStartup(&token, &input,>NULL); } >void FSAPI module_deinit(void) {GdiplusShutdown (token);} >>token and input are global variables>>don't forget include required headers there :)How can you do this when all Gdiplus stuff is C++???? Are you using a .cpp main gauge file in your multi-gauge? Mine have always been .c, and therefore the above won't work as it is C++.Could you be more specific on how you are doing this? I've always had to have the one main file be .c.With this singleton, you can init GdiPlus, but you have to avoid the dreaded "order of initialization" problem by making sure you put the Instance() call in the right place.// GdiPlusManager.cpp//// Copyright © 2006 Benchmark Avionics Corporation. All rights reserved.#include "GdiPlusManager.h"namespace Helpers{ GDIPlusManager* GDIPlusManager::m_pInstance = 0; GDIPlusManager* GDIPlusManager::Instance() { if(m_pInstance == 0) m_pInstance = new GDIPlusManager(); return m_pInstance; } GDIPlusManager::GDIPlusManager() { gdiplusToken = 0; // Instantiate class to initialize GDI+ Gdiplus::GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL); } GDIPlusManager::~GDIPlusManager() { // Destructor will shutdown GDI+ when class goes out of scope on termination Gdiplus::GdiplusShutdown(gdiplusToken); }}

Share this post


Link to post
Share on other sites

Seeing as how I'm a simple man, I seek out simple, universal solutions. The following allows me to not worry about gauge loading sequence, and creates ONE set of "drawing tools" that may be used by any GDI+ gauges that need 'em... ;)case PANEL_SERVICE_CONNECT_TO_WINDOW: gdiPlusUsers++; if(!init_gdiPlus) { GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL); init_gdiPlus = true; } if(init_gdiPlus && !objects_created) { img_attr = new ImageAttributes(); CreateTools(); //create Pens, Brushes and Fonts bool objects_created = true; }break;case PANEL_SERVICE_DISCONNECT: gdiPlusUsers--; if (init_gdiPlus && gdiPlusUsers == 0) { GdiplusShutdown(gdiplusToken); init_gdiPlus = false; } if(objects_created) { DeleteTools(); //delete Pens, Brushes and Fonts objects_created = false; }break;

Share this post


Link to post
Share on other sites

The line "bool objects_created = true;" isn't a good thing. It defines the variable "objects_created" right at that point. It is not guaranteed to always have the correct value on each cycle.You would be better off declaring it in the main .h file for your gauge package.

Share this post


Link to post
Share on other sites

>The line "bool objects_created = true;" isn't a good thing. >It defines the variable "objects_created" right at that point.> It is not guaranteed to always have the correct value on each>cycle.>>You would be better off declaring it in the main .h file for>your gauge package.Ah! Quite right... moved now... Thanks for the quick eye, Ed! ;)

Share this post


Link to post
Share on other sites

That approach doesn't work when you are using statically created Gdi+ stuff instantiated in another object, which is why I had to deviate from it in the first place.But, no worries, my singleton class works fine.Really, I was trying to figure out why I couldn't compile the master .c file as .cpp, but as you know Bill from my email, something else was mucking that up and is solved.So, I could now use the mod_init thing if I wanted also.Again, good to see how others are doing things as options are always nice.The advantage to having static colors, pens, and brushes made it worthwhile for me to figure out how to do it.

Share this post


Link to post
Share on other sites

What advantage would that be?I really can't think of any.

Share this post


Link to post
Share on other sites

Our rather large project, an FMS, requires it for OO design reasons, reduces complexity, improves maintainability, improves performance, reduces storage requirments, and allow us to do what we need to do.Anyway, my point was just that if your design calls for static Gdi+ stuff, the technique above won't work, and I wanted to document that fact for those that might otherwise not understand why things weren't working for them as it is not obvious.If you don't see a need for them, by all means reduce your complexity and don't use them.

Share this post


Link to post
Share on other sites

I think ya misunderstood my post.You said "The advantage to having static colors, pens, and brushes made it worthwhile for me to figure out how to do it."I simply wanted to know what advantages were offered using static colors, pens and brushes. Your post nicely explains why you must use them... though... gotta say your post has something amusing in it... and I am NOT pointing this out as a slight or a dig, just a 'ha-ha' funny. ;)In your first sentence you say it 'reduces complexity'... in the last sentence you suggest not using them to 'reduce complexity'. Now I know what you mean... but it's still amusing to my simple little mind. ;)

Share this post


Link to post
Share on other sites

Ed,Yeah, I thought you would notice that and not get my context.To be more precise, I should say that it reduces complex in the code (although for me it was complex to figure out initially). It does this the way any static var does, and I won't bother to explain something so basic here (which I'm confident you likely understand anyway). For those who want to know more, I highly recommend working through Headstart Design Patterns (it's in Java, but you can translate), and C++ Primer 5th Edition.And what I'm saying, is that if it only introduces complexity for others because they don't need it, then clearly it is not advantageous.I just prefer coding the way something should be designed (which is not to say that every design should use them), rather than limiting myself because I can't figure out how to do it. But then, with all of us helping each other with how to do things, we can take some of the sting out of learning them. I'm more than willing to share how to do this if someone determines they need them. That's why I posted my singleton class.Perhaps someone will improve upon my start as well. My hope is that Benchmark will soon have a sourceforge site up were some useful classes will be posted for others to use and contribute too.Sorry, I'm just so busy coding that I didn't bother to be more precise.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this