MapPoint Plugin

[pv]

Here is a teaser screenshot of my working MapPoint 2004 plugin:

(I promise this is a real screenshot of the working plugin)

MapPoint 2006 does not add enough features to justify supporting it...yet (but it should be pretty easy).
http://msdn.microsoft.com/library/en...OMWhatsNew.asp

I will post the code on www.gotdotnet.com once their site becomes reliable again and when I work out a few remaining kinks.

FYI: GDN is erroring out with both IE and Firefox w/ cleared caches.
If their server has gone down again then this will be the 3rd project I have lost to that site.
I still have my local code; I would need to find a new place to host it.
Hopefully GDN's problems are just temporary.

Now, for the reason for this posting:
I am running in to a UI corruption in CF when I load my MapPoint plugin.
After CF copies and installs the plugin , the text for the other plugins gets a little screwy or is entirely blank (I see the other plugins' icons, but not all of their text).
Some of the standard CF dialogs also get corrupted.

I get the following error in the error.log file:
6/12/2006 1:24:09 AM
Input string was not in a correct format.
at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at centrafuse.Plugins.CFPlugin.setbuttonskin(String whichbutton, Int32 which, String btext, Boolean useglobal, MouseEventHandler clickEvent, MouseEventHandler downEvent)
----------------------------------------------------------------------------------------------------------

I cannot tell what is reporting this error.
I have set a breakpoint in all of the plugin's catch statements but I do not hit any of them.
If I don't load my plugin then there are no errors.
CF itself seems to be reporting the error.
I typically always debug w/ centrafuse loading my plugin, but I don't see the debug output reporting any error.

Are there any best practices or troubleshooting tips for finding out what is corrupting the UI or reporting the error.log entry(s)?

I am using the standard v1.6 Onyx plugin.
The plugin code is rip-off of the web example code.
The plugin skin is a rip-off of the destinator skin.
The code and skin looks pretty clean to me...again I will share it out once I find a good spot to post it officially.

Any there any other good source code management sites out there other than sourceforge and gotdotnet? (preferrably one w/ a source control plugin for VisualStudio).

Thanks!

Pv

[David]

That error means it cannot read from one of the skin.xml files one of the buttons you have...

at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
at centrafuse.Plugins.CFPlugin.setbuttonskin(String whichbutton, Int32 which, String btext, Boolean useglobal, MouseEventHandler

This means under one of the BUTTON nodes for one of the sections you do not have a number in a field that should be a number... This can sometimes cause the processing to stop and therefore would cause the rest of the plugins to stop loading...

This could also be called if you tried to create a button in the CFPlugin that did not have a matching node in the XML file to read from...

The plugin looks great!

david

[pv]

I compared my modified version of the destinator skin.xml to the original.

I *did* remove what I thought to be a duplicated entry for the FULLMENU button.
In the orignal skin it was defined at 0,0,206,50 and 386,0,141,50
Otherwise the skin is exactly the same except for where is changed "DESTINATOR" to "CFMAPPOINT".

I will look in to this some more.
Is there a way to more easily tell which button is causing the problem?
Maybe a verbose logging mode?

Pv

[pv]

I resolved the error.log entry.
My code was indeed trying to load a button that was not defined.

However, I still get the same behavior in CF.
The title for the phone, web, obdii, etc plugs is blank.
The settings/plugin dialog is all black except for the text of the installed plugins.

This open happens when I install my CFMapPoint plugin.
If I delete the plugin from the plugins dir then then problem doesn't happen.

Hmmm...more investigation...

[pv]

Figured it out...but I'm a tad bit confused.
I originally had something like this:

void CF_pluginInit()
{
  this.axControl = new AxControl(...);
  (System.Component.ISupportInitialize)(this.axControl).BeginInit();
  this.axControl.Bounds = ...;
  this.Controls.Add(this.axControl);
  (System.Component.ISupportInitialize)(this.axControl).EndInit();
  this.ResumeLayout(false);
  AXInit();
}

void AXInit()
{
  this.axControl.NewMap(...);
}

I changed it to this:

void CF_pluginInit()
{
  this.axControl = new AxControl(...);
  (System.Component.ISupportInitialize)(this.axControl).BeginInit();
  this.axControl.Bounds = ...;
  this.Controls.Add(this.axControl);
  (System.Component.ISupportInitialize)(this.axControl).EndInit();
  this.ResumeLayout(false);
}

void CF_pluginShow()
{
  AXInit();
}

void AXInit()
{
  this.axControl.NewMap(...);
}

Basically, if I tried to use the activex object in CF_plugInit then CF would appear to get corrupted.
Now that I have moved AXInit in to CF_pluginShow, CF appears to load fasters and not get corrupted.[/code]

[David]

I have seen this before where COM objects, and some other objects, do not like to create GUI windows within pluginInit...

I generally do this in Show just as you have figured out... This is most likely do to when I load and scan all plugins initially, I do it in a seperate application domain, some COM objects do not like to create GUI windows within this secondary domain and do not transfer over to the primary GUI thread once I unload the secondary appliation domain and transfer the valid Plugin objects to the primary application domain and assign their Owner form to the main CF_Main handle...

hope that makes some sense...

david

[pv]

Makes sense.
The plugin problem now appears to be fixed.

Other good news; the gotdotnet team is working on fixing the GDN problem.
In the next few days I should be able to post a stable project up on gotdotnet.

It will *currently only* have the following features:

• * Basic MapPoint map data
  * Zoom In/Out
  * Drag and WindowZoom modes
  * Primitive GPS support (current location only, perhaps always locked)

I still need to brainstorm some of the UI (route, find, nearby, etc) and how it will fit in to CF.
My old code just uses Windows.Forms.Panels to show/hide listboxes that do route, find, nearby, etc.
I would like to come up w/ a skinned solution.
That takes some time (especially for a new CF skinner).

Pv

[David]

Here are the screenshots of how all the dialogs work in the new GPS system that uses the Destinator engine...

http://www.mp3car.com/vbulletin/showthread.php?t=75987

All the dialogs should be easy to adapt and replace the Destinator code with the similiar MapPoint code...

I currently had no plans to release any source from my GPS plugin, but I might can work something out with you on getting you just the extra dialogs you need...

Is this something you wanted to put on gotdot.net for sure? Either way I'm sure we will work something out and I might be able to send the new images and actual dialog classes you would need for everything in a couple days...

I would need the time to clean up the code and add a few comments

david

[pv]

Thanks, I'll try to give those a scrub!

I have working GPS code, so I would only need to reverse engineer the dialogs that are already visible in the skins dir.

Hosting this on GDN is fine w/ me, as long as they stop breaking the site every few months!

I would gladly take you up on any predefined dialog classes that you are willing to provide, but don't go out of your way for this.
Skinned dialogs don't seem too bad to create, I am just looking for a way to make it work well on the screen.

MP and Destinator may have subtle diffs in their object model that may make it difficult to present their info in the same.
MP can't do some of the things that Dest can (and vicea/versa?), so I might as well make my plugin a best fit for MP.

Anyone got any CF MapPoint plugin prototype concepts?
Later this evening I will post my existing ones from an older MP app I wrote.

Pv

[pv]

Here is a concept from my old plugin:









The UI was very usable, but it lacked an OSK.
The trick for a CF MapPoint plugin is that I want the map to be visible behind the dialogs, especially the Find dialog
When you "Find" something you should be able to zoom in/out and pan around to visually verify that the result is what you want.
The "Route" does not need to interact with the map until you hit Calculate, but it would be nice to see and confirm the final route result before you close the dialogs.

Pv