Big bug in Rhino panels, SR1

There is a big bug which breaks Rhino panels UI drawing in SR1.

  1. Opening a panel raises two times the event “VisibleChanged” event.
  2. Closing a panel raises two times the event “VisibleChanged” event but Visibility property is True, in SR0 it was False which is the right one.
  3. Closing the panel makes that all the other panels of the container have the closed panel inside but without any background. (see the following video)

Here the code:

Plugin:

public class PanelBugRh6Sr1PlugIn : PlugIn
    {
        public PanelBugRh6Sr1PlugIn()
        {
            Instance = this;
        }

        public static PanelBugRh6Sr1PlugIn Instance { get; private set; }

        protected override LoadReturnCode OnLoad(ref string errorMessage)
        {
            Panels.RegisterPanel(this, typeof(PanelTestCtrl), "TestPanel", System.Drawing.SystemIcons.Application);
            return base.OnLoad(ref errorMessage);
        }
    }

Open panel command:

public class PanelBugRh6Sr1CommandOpen : Command
    {
        public PanelBugRh6Sr1CommandOpen()
        {
            Instance = this;
        }

        ///<summary>The only instance of this command.</summary>
        public static PanelBugRh6Sr1CommandOpen Instance { get; private set; }

        public override string EnglishName => "PanelBugRh6Sr1CommandOpen";

        protected override Result RunCommand(RhinoDoc doc, RunMode mode)
        {
            return Panels.OpenPanelAsSibling(PanelTestCtrl.Id, PanelIds.Layers) ? Result.Success : Result.Failure;
        }
    }

Close Panel Command:

public class PanelBugRh6Sr1CommandClose : Command
    {
        public PanelBugRh6Sr1CommandClose()
        {
            Instance = this;
        }

        public static PanelBugRh6Sr1CommandClose Instance { get; private set; }

        public override string EnglishName => "PanelBugRh6Sr1CommandClose";

        protected override Result RunCommand(RhinoDoc doc, RunMode mode)
        {
            Panels.ClosePanel(typeof(PanelTestCtrl));
            return Result.Success;
        }
    }

Here the example plugin source code with the rhp file: PanelBug_Rh6_Sr1.7z (206.9 KB)
I hope you can fix it soon, so it’s breaking all the workflow of our plugin.

Thanks and best regards.

Enric

I was able to reproduce this and am in the progress of fixing it, see RH-44059

RH-44059 Has now been fixed, this should work correctly in the next SR2 build.

Thank you for the quick fix @JohnM , should it be working fine in the latest release candidate?

Thanks and best regards.

Yes, it should be in the latest SR2 release candidate.

Hi @JohnM

I’m afraid it’s not fixed, so take a look at this short video showing the multiple fail cases.

  1. First time It raises the VisibiltyChanged event 2 times when it turns Visible
  2. Next times the VisibiltyChanged when panel is shown, is not raised
  3. When Panel is hidden it raises VisibiltyChanged as Visible = True
  4. The Panels.Show event is raised multiple times (I check the Id of the panel if is not the right one, it returns)
  5. Showing the panel raises the event 4 times as False, and finally 1 as True
  6. Changing between other panels (Layers and properties for example) raises the Panels.Show as false

Here the video:

Here the exemple project:
PanelBug_Rh6_Sr1.zip (351.0 KB)

I used Rhino 6.2 RC

Thanks and Regards

Not looking at the code yet, but you may want to at least want to fix your .csproj to point to the correct RhinoCommon location. It currently has a relative path something like ..\..\..\Program Files\Rhinoceros 6\System\RhinoCommon.dll, but you have it probably installed under C:\Program Files\Rhino 6\System\RhinoCommon.dll

Hi Nathan,

I’m sorry I forgot to change the path, anyway in my case it’s right, Rhino is installed in C:\Program Files\Rhinoceros 6

Then I don’t see how your Rhino.UI.dll reference works? Because that is pointing to the Rhino 6 folder I mentioned…
image

Hi @nathanletwory ,

I forgot to replace Rhinocommon path, I updated all references to point to default Rhino installation C:\Program Files\Rhino 6\
now the sample project should work with a default Rhino installation.

PanelBug_Rh6_Sr1.7z (219.8 KB)

I also manually changed it - just wanted to notify you of it :slight_smile:

I’ll let @JohnM answer this, he’s more intimate with the code in question.

:+1: Great!

Thanks Nathan.

I reported this as RH-44287 and am in the process of committing a fix for this issue. The fix should be available in todays Rhino service release preview.

Okay, I’ll check it out, thanks Jhon!

RH-44287 is fixed in the latest Service Release Candidate

Hi @brian,

Thanks for the effort but it keeps failing:

  1. Opening a panel raises VisibleChanged event 3 times (true, false and true)
  2. Opening another panel raises last panel Show event set to Visible=TRUE, next raises last panel Show event 4 times Visible=FALSE
  3. Switching between Rhino or other panels keeps raising hidden panels Show event set to FALSE.
  4. Hidding a panel by code (opening Rhino Properties panel) raises Show event set to TRUE for the current panel 4 times, VisibleChanged event set to False, and finally Show event set to False, (also Show event is raised 2 times per any of the other panels, in this case Panel2)
  5. Closing the panel by code raisesShow event for this panel 7 times set to TRUE but never Show event set to FALSE, also raises VisibleChanged event 2 times (one False and another True, furthermore the Close event 2 times.

Here a video showing the issues:

I would like to remark that every panel Show or Close event has a check like this:

private static void Panels_Show(object sender, ShowPanelEventArgs e)
{
     if (e.PanelId != Id) return;
     RhinoApp.WriteLine($"Panel 1 Show raised = {e.Show}");
 }

So even the event is raised for another panel there is a check which returns if the args Id doesn’t match.

Best Regards and Good Luck

You are correct, the underlying code that activates a panel in a dock bar calls hide on all but the newly active panel tab to ensure the panels visibility state is correct which you can see by the events being raised. The states are correct even if the notifications are redundant. I will take a look in a bit and see if I can filter out redundant events.

Logged the duplicate notification messages as RH-44382.