Announcement

Collapse
No announcement yet.

Switch-to messages, plugin restart, and plugin startup

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Switch-to messages, plugin restart, and plugin startup

    Some users of the mcsTemperature plugin are experiencing lockup-type conditions when exiting the setup page associated with the plugin. Detailed debug statements have been inserted and a trace log using hs.debug also produced with no evidence of the source of the problem.

    The plugin code invloved consists of a form with a load procedure, an unload procedure, and a cancel (or update) button. The code is as follows:
    <pre class="ip-ubbcode-code-pre">
    hspi_mcstemperature Class called by homeseer when user selects Setup button
    ------------------------
    Public Sub ConfigIO()
    Dialog.Show vbModal
    End Sub

    dialog form
    ------------
    Private Sub Form_Load()
    On Error GoTo Error_Exit
    &lt;initialize bunch of global variables&gt;
    Normal_Exit:
    Exit Sub
    Error_Exit:
    hs.writelog "mcsTemperature Plugin", "Setup Load: " & Err.description
    Resume Normal_Exit
    End Sub

    Private Sub Form_unload(Cancel As Integer)
    End Sub

    cancel button on dialog form
    ----------------------------
    Private Sub CancelButton_Click()
    On Error Resume Next
    hs.writelog "debug","Before Unload"
    Unload Me
    hs.writelog "debug","After Unload"
    End Sub
    </pre>

    The homeseer log shows the two debug statements being executed as a result of the cancel button being clicked. It then shows that it is shutting down and then startup messages appear for the mcsTemperature and the MR26 plugins (both .exe plugins). This sequence is also accompanied by a windows message like "Switch-to or Retry" because the application is not responding.

    The homeseer trace log also shows the normal actions being performed by the mcsTemperature plugin on 1 minute intervals based upon an internal timer within the plugin. It is the act of trying to close the setup page that induces the failure modes.

    Any suggestions as to what could be happening?


    A second odd behavior, that apparrently only I have observed is at the startup of homeseer. A splash screen appears and in the past it would normally exists for only a few seconds. It now remains up for 3 minutes with the status lines showing "Checking HSPIMCSTEMPERATURE.hspi". During this 3 minute period I can observe the mcsTemperature.exe process running with about 2M or memory utilized. Debug statements were included in every entry point that homeseer may reference, including Class_Initialize. None of these were entered during this 3 minute period.
    After the 3 minute period the memory use goes up to around 8M.

    I also observed that plugins were being checked that I have previously installed but since have removed. I also removed the .exe/.ocx from the directory. It appears that once a plugin is installed homeseer will then always be looking for it even if it no longer exists on the computer.

    The 3 minute startup does not affect the operation, but it is an annoyance.

    What is homeseer really doing when it shows the "checking" message?

    #2
    Michael,
    While beta testing a new Vid Cap plugin, I had a need to check some registry settings. I have since found that once a plugin is installed, one that is registered by way of regserver in any way, it's "keys" remain in the registry. This causes problems with HS when changing plugin versions or plugin names. What I believe we need is for HS to cleanup after itself when a plugin is removed from the interfaces tab or do as I have and manually clean them. The updater even fails at cleaning up the registry with old versions. I have a few great utility's that I will share, if anyone wants and understands the registry enough to try....JG

    The Garage
    3.0.0.548: HS3PRO - 3.0.5.10: AIAlert - 2.1.1.0: APIWeather - 2.0.64.0: BLBackup - 2.0.45.0: BLLAN - 2.0.37.0: BLRoombaWifi - 1.0.0.3: DevLog - 1.2.5.15: KeyPad - 3.0.2.25: NetCAM - 0.0.0.52: Pushover 3P - 3.0.0.5: SendVFD - 1.0.0.3: Tiles - 3.0.11.0: Z-Wave

    Comment


      #3
      Michael,

      I had virtually the same thing happen in the plugin I'm working on. I had several things executing during the RegCallback (or whatever it's called), and it allowed the timers to get started. It never would recover until I removed all initialization out of the function (or sub). I had to lock out my timer on it's first execution by setting a boolean variable, but mine are on a 15 second interval.
      Also, check your timers for "ghosting". Put some hs.Writelog's in them to see if you are getting more than one instance of your timer. (If you are, we need to talk.)

      Oh, and check the splash screen for style. If a form is displayed as modal, the code following the Show method is not executed until the dialog box is closed. However, when a form is shown as modeless, the code following the Show method is executed immediately after the form is displayed. You may have inadvertantly changed it.

      regards,

      GenevaDude

      Comment


        #4
        I found that when you open a form as modal, you may have to force it to the front. You can do that with the command

        callback.ForceFront Me.hwnd

        in the load event of the modal form. I'm wondering about code after the unload command in your click event. When you execute the unload command the unload form event fires - it may be confusing things. In my plugin, I don't execute any code after the unload command and it's pretty reliable.

        And JEBUS is correct about the registry keys sticking around if you simply replace an activeX EXE. We've been all through that one! The HS Updater does to the proper unregistering and re-registering (if instructed to in the setup Install.txt) when replacing a plugin EXE.

        Bryan
        (Config is in my profile)
        Bryan
        (Config is in my profile)

        Comment


          #5
          GenevaDude,
          My callback section is void of everything except the callback. I also have debug with the timer and only one instance. The timer is disabled on the form and programatically started in the form_load procedure which itself is called at the end of the Init_io call from homeseer. This form contains only the timer and mscomm controls and stays loaded until homeseer's shutdown_io call.

          The setup page in question does have the mode set to vbModal. This is legacy from the plugin SDK. It seems to me that it does not make sense for an .exe plugin to use vbModal in this context since it would seem to want to pause execution of the homeseer thread which I do not want to do. In actuality I can access both the homeseer GUI and plugin's setup page at the same time so it behaves as if vbModal does not apply across processes. I changed it just to see if it makes a difference.

          Jebus,
          I've poked into the registry but have only done simple things with it. I would like to do some exploring with the aid of useful tools if you could be so kind.

          Comment

          Working...
          X