[Approved] Patch to enhance TV notification (1 Viewer)

[splatterpop]

Hi DieBagger,

thanks for the input, that helped.

However GetWindow(...WINDOW_DIALOG_YES_NO) refuses to work with the subclassed notification dialog (InvalidCastException). I created

class TvProgramNotifyDlg : MediaPortal.Dialogs.GUIDialogYesNo
{
...
}

to implement the new timeout functions. I'm stuck.

 

[matejdro]

Can that feature gets into MP release?

 

[DieBagger]

Hi DieBagger,

thanks for the input, that helped.

However GetWindow(...WINDOW_DIALOG_YES_NO) refuses to work with the subclassed notification dialog (InvalidCastException). I created

class TvProgramNotifyDlg : MediaPortal.Dialogs.GUIDialogYesNo
{
...
}

to implement the new timeout functions. I'm stuck.

Hey man, sry for the late reply, I completely missed your post...

I would GUESS that you need to add your subclassed dialog to some sort of list of available dialogs (just a wild guess). I will try to get a dev to look at this, can you post some more info (what did you do, how did you do it?).

 

[riksmith]

The problem is you are using the WINDOW_DIALOG_YES_NO constant. You should define your own window id for this dialog (in GUIWindow.cs).

You can then set it like this (just as GUIDialogYesNo does it)

public TvProgramNotifyDlg ()
    {
      GetID = (int)Window.WINDOW_DIALOG_PROGRAM_NOTIFY;
    }

The plugin manager will then register this window in the window manager and after that you can use it just like the yes_no dialog.

 

[DieBagger]

Hey splatterpop, any word on the patch?

Did the suggestion from riksmith help you or do you still have some problems? I updated the status to WIP and will change to evaluating once we have an updated patch.

 

[splatterpop]

Sorry guys I was on a vacation. Thanks for all your input.

I tried riksmith's approach, which produces an exception. I believe a new window id (I tried 103) also requires a additional skin file, right? This is something I would very much like to avoid. It contradicts DieBagger's original idea somehow.

DieBagger, I would like to proceed the subclassing way but I cant see how it can be done, considering the fact that each gui window class is instantiated once at program startup. Here in this case we would need two instances (YesNo and Notification) which share a common skin resource. Is this possible at all?

Current implementation of the notification dialog, currently located in TvNotifyManager.cs:

  class TvProgramNotifyDlg : MediaPortal.Dialogs.GUIDialogYesNo
  {
    private int timeOutInSeconds = 0;
    private DateTime timeStart = DateTime.Now;

    public TvProgramNotifyDlg()
    {
    }

    public int TimeOut
    {
      get { return timeOutInSeconds; }
      set { timeOutInSeconds = value; }
    }

    public override bool ProcessDoModal()
    {
      base.ProcessDoModal();
      TimeSpan timeElapsed = DateTime.Now - timeStart;
      if (TimeOut > 0)
      {
        if (timeElapsed.TotalSeconds >= TimeOut)
        {
          GUIMessage msgConfirmYes = new GUIMessage();
          msgConfirmYes.Message = GUIMessage.MessageType.GUI_MSG_CLICKED;
          msgConfirmYes.SenderControlId = base.btnYes.GetID;
          base.OnMessage(msgConfirmYes);
          // m_bConfirmed = m_DefaultYes;
          return false;
        }
      }
      return true;
    }

    public override void DoModal(int dwParentId)
    {
      timeStart = DateTime.Now;
      base.DoModal(dwParentId);
    }
  }

ProcessDoModal is of course untested and incomplete.

Greetings,
splatterpop

 

[splatterpop]

Any ideas?

 

[jameson_uk]

Any ideas?

Can you post a full patch of what you have so far and I will try and have a look

 

[gemx]

Every window has to have it's own id.

If you are inheriting from another class, then your class must have it's own id.

That has nothing to do with the skinfile.

You explicitly state the skin file to use in the class (i think it was the "Init" method).

If you don't override this method in your successor class then it's ok and you use the same skin file like the superclass

 

[splatterpop]

Hi Jameson, please find attached the patch which reflects the current state of my work.

gemx, yes that was my intention too. However I found that using new() to create an instance of the derived dialog class fails to initialize the controls. I fould it also impossible to use GetWindow() to access the actual instance of the yes/no dialog (which contains the loaded skin resources).

Correct me if I'm wrong. The way I see it, each GUI window class is instantiated once at program startup, which is why each GUI window can be accessed through GetWindow() (accessing the object in memory) instead of using new(). The problem is: merely deriving a class from a predefined GUI window class (same Window ID) class does not work because the derived class cannot be accessed through GetWindow() which gives InvalidCast exception. Using new() gives the correct type but does not work either, because this new object is not initialized properly.

Thanks for your input.

Greetings,
splatterpop