plug ins not showing in 4.80, one one laptop, work on another?

[bdbcat]

Rick...

re:

"Is there a mandate that to compile plugins we should now use only
'opencpn.lib' from Opencpn v4.2 (as the "oldest" useful version)?"


Not really a mandate, more a practical matter. Plugins for OCPN prior to v4.2 are not being maintained, and for good reason. We want users to be on the most current release of O. And this is where we should concentrate our limited development resources.

I expect at some soon point we will de-emphasize (or remove entirely) the pre-v4.2 Plugins from the .org site They generate very little download traffic or interest.

This is what the opencpn.org site says now:

"Important note for OpenCPN 4.0 (and earlier) users. Upgrade to the latest version of OpenCPN. Really. It is much better and more stable than the version you are running now. We will not post any more updates to the older version plugins available here, ever."


Dave

[Hakan]

Originally Posted by bdbcat

So, if you can catch a failure when you friend returns next week, by all means we would like to see the contents of the plugin subdirectories

Very well! I'll try to catch the files and come back here with a link.

This community is indeed great.
Thanks
Håkan

[transmitterdan]

I added a try/catch handler to the pluginDebug branch of my O fork. It will not solve the problem but it will log any plugin that throws a runtime exception during the load process. It will also throw up a dialog box giving the name of the offending dll.

[Hakan]

TDan..
Splendid! I've built and run it wo problem for a "normal" O setup.
I'll see if I can make a fake dll to make further tests. And of course test when we get hands on a fake library.

The "try" method must be a adequate tool for what we are looking for. At least to my limited knowledge.

Thanks
Håkan

[Hakan]

TDan..
And I've tried to load an outdated plugin and the black list procedure is still working and messaging as it should.
Håkan

[transmitterdan]

Originally Posted by Hakan

TDan..
Splendid! I've built and run it wo problem for a "normal" O setup.
I'll see if I can make a fake dll to make further tests. And of course test when we get hands on a fake library.

The "try" method must be a adequate tool for what we are looking for. At least to my limited knowledge.

Thanks
Håkan

It should be enough to tell us exactly which plugin is causing the fault. But be aware that the try/catch system is only there to tell us about the fault. It cannot correct the fault after the plugin has upset the runtime library. O will most likely exit or crash after showing the message about the offending plugin.

[Hakan]

To tell the user that something is wrong and point to a cause is exactly what we need here, I suppose. This kind of failure is really not common and most probably a result of a more or less unconsciousness user error. So if your "try" logic can point it out I think that's good enough.
Håkan

[rgleason]

Thanks all. Bdbcat. I think you point is good to limit resources to the current release forward and to completely remove anything before 4.2.

Following that suggestion, I will remove all pi previous to 4.2 on file thingie to. Its time for a big cleanup and out there.

Also will have your succint pi list tonight or tomorrow. May be in two parts. Sean & and Stelian are fixing/improving cel nav.

[Hakan]

TDan, Dave...
Here's a link to the plugins folder causing freeze and a blank plugins tab for my friend. https://www.dropbox.com/s/v05f3xdriv...ugins.zip?dl=1
I've used it on Tdan's branch "plugindebug" and then the blacklist method works as it should.
Håkan

[transmitterdan]

Hakan,

Could you tell which plugin was causing the freeze?

[transmitterdan]

I tested this and can pretty much duplicate the problem reported by others. Here is what I found so far:

1) The S63 plugin is "incompatible" with 4.8.0 and O correctly detects this when navigating to the plugins tab of options. It pops up a dialog box saying the plugin is not compatible.

2) After clicking OK the plugin screen appears blank and seems to sit there. Eventually the screen goes away. But it isn't "gone" it is just sitting behind the O main screen and the warning dialog about the S63 plugin is still there too. But you cannot navigate to it because Windows insists on showing the main O screen and not the plugin incompatible message box. Since message box is a modal dialog you cannot do anything in the main O screen. Any click of the mouse gets a sound from Windows indicating that is not allowed. Thus the report that "O is frozen". It's not really frozen it's just in a catatonic state because the message box dialog is the only thing accepting input but it is not shown. Thus a catch-22.

I will look into it more in a couple days. But for now we know the S63 plugin is most likely the culprit. And I suspect there is some issue surrounding what happens when the message box is trying to close. This should not be too hard to diagnose and fix.

[transmitterdan]

Update:

I added a log message to see what O doesn't like about the S63 plugin. This is the code snippet of the extra log message in PlugInManager::CheckPluginCompatibility()

            if (strstr(libname[i], "wx") != NULL)
            {
                if (strstr(libname[i], strver) == NULL) {
                    b_compat = false;
                    wxLogMessage( wxString::Format(_("Incompatible library %s used by %s."), libname[i], plugin_file) );
                }
                break;

Spookily now everything works as it should. The plugin is not loaded and the plugin tab is correctly filled in with the remaining good plugins. I have no idea why adding a log message here would make the bug go away.

PS: My original theory was all wrong. The S63 plugin is never actually loaded by O so it never gets a chance to hose up the runtime library. The bug has to do with modal dialogs getting hung up behind the main O screen resulting in a catch-22 as described earlier. I still have no idea why adding that one line of additional log message works. It should not have changed anything. Could it be some wx bug?

Hakan, I have updated my pluginDebug branch with this additional log message. It seems to have cured the entire problem. Can you try it on your friends computer without the -d command line option. See if it works now without hanging.

[Hakan]

TDan..
Very good catch indeed!! It's amazing how a "simple" failure can create a lot of work and frustration.
I've run your last commit from "plugindebug" and the dialog box is in front and activated all times.
And, yes, it's strange that when I use opencpn.exe from official 4.8 the dialog is very well hidden and can't be found. If there it must be behind O and not options tab? And the plugin tab is empty. The dialog should have a time out at 10 sec?? And the freeze is there instead.

So - I built and run "plugindebug" instead. Now the plugin dialog is there again, well in front??
The OCPNMessageBox is coded in the same way on both builds.
Whatever you did it seams to work.

Håkan

[Hakan]

TDan..
If nothing else is coming up I'll tomorrow transfer a O-installer from your latest "plugindebug" to my friend and let him test on the original plugin folders we've now tried.
Håkan

[transmitterdan]

Hakan,

The way I found the hung dialog box was using Windows 10. If I position the mouse over the O icon on the task bar and wait it shows a miniature screen shot of O. If i leave the mouse there a while longer it shows the entire dialog box stack up in miniature. That is how I surmised about the hung dialog. That is not 100% proof because windows sometimes caches screen shots and i may be looking at a stale screen grab.