LockedList plug-in

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Animaether
    Major Dude
    • Jun 2001
    • 1173

    #76
    AddApplication? I saw the AddApplications method (not documented, but in the examples), but figured that was a bit heavy-handed; other (InstallShield, I think) installers claiming every single application must be closed (usually for no good reason) often just tend to annoy me

    Short of creating a completely custom page - is there any way to add to the LockedList list manually? I suppose through poking at SysListView32 directly, if nothing else. Might be cleaner to add a method to add custom data, but I'm not sure how that would interfere with things like the context menu, automatic clearing of items, etc.

    Comment

    • Animaether
      Major Dude
      • Jun 2001
      • 1173

      #77
      oh, on a rather unrelated note, I'm still getting the odd bits in the top of the list - but the new version at least seems to spit out some useful information; it reports the process ID as 4 (which, according to taskman, is the System process).
      This is from the supplied module/notepad example:


      I have no idea why it's listing that - notepad certainly isn't running (if it is, it adds a 2nd line listing notepad itself). Windows XP, 32bit, SP2 and any other information you'd need, just say the word

      Comment

      • Afrow UK
        Moderator
        • Nov 2002
        • 8434

        #78
        Sorry should have mentioned that was fixed a few mins after I uploaded. Yeh not sure why I added AddApplications - someone must have asked for it. Probably useful if you are going to be rebooting the system after installation and you don't want people to lose their work. How about AddClass or AddCaption? How would adding custom data work?

        If your application is 64-bit, did you try adding the actual executable using AddModule? That should work.

        Stu

        Comment

        • Animaether
          Major Dude
          • Jun 2001
          • 1173

          #79
          Ah, I'll have to re-test.

          =====

          Unfortunately, AddClass, AddCaption, looping over processes etc. wouldn't do much good as I don't have the particulars of the application(s) that might use these libraries. They're basically DLLs that other developers can, and are likely to, make use of.. but I don't think we can dictate "Thou Shalt Useth This Class"

          Adding (err.. and removing, I suppose) custom data basically just to populate the list and have LockedList realize whether the list is empty or not.

          E.g. Let's say I run my own function to at least check if -something- is locking a 64bit file.. I can't tell what is locking it, but at least I can tell the user that something is. Quite possibly, they'll know what's locking it and can then close it.

          So having identified that a particular file is locked, say I call:
          LockedList::AddCustomItem "path\filename" ["unknown process"]
          That adds the custom item to the locked list internal list and display list. The display list so that, obviously, it is displayed..and the internal list so that if the other locks that LockedList handled itself are closed, it doesn't immediately report that there's nothing left to close.

          This would require a companion function a la...
          LockedList::RemoveCustomItem "path\filename" that would remove the matching item. I'm *presuming* that it wouldn't require some manner of unique ID to be returned from AddCustomItem that would then get fed to RemoveCustomItem, instead just string matching.. but whatever is easier/better/etc.
          This function would get called if my own function determines that said lock is, in fact, gone.

          Unfortunately this probably means quite a few other changes - can't just add an nsDialogs timer to your dialog to periodically call my function / add a button to manually refresh / etc. so the plugin would have to call it and so forth and so on.

          Hence why I was already thinking that -maybe- it's better I create my own custom page with a list (probably through EmbeddedList), and populate that out of the LockedList stack methods. I'd lose the automatic checking - instead having to re-requery LockedList.. or.. actually I guess I can just check if the process that LockedList reported is still present when I do my refresh.. that should have the same effect?

          I'd better check that System process bit first

          Comment

          • Animaether
            Major Dude
            • Jun 2001
            • 1173

            #80
            System process being reported has indeed been fixed - thanks!

            Comment

            • Afrow UK
              Moderator
              • Nov 2002
              • 8434

              #81
              How about this:
              code:
              AddCustom [/icon path] application process callback
              Usage:
              code:
              GetFunctionAddress $R0 IsMyAppRunning
              LockedList::AddCustom /icon $PLUGINSDIR\icon.ico "My App" "myapp.exe" $R0

              code:
              Function IsMyAppRunning
              Pop $R0 ; $R0 = myapp.exe in case you want to know
              ${If} [myapp is locking files]
              Push true
              ${Else}
              Push false
              ${EndIf}
              FunctionEnd

              Stu

              Comment

              • Animaether
                Major Dude
                • Jun 2001
                • 1173

                #82
                Yeah, seems like that would work (and be more flexible for general use). How often would the callback be called? Unless it blocks the thread, etc.

                Comment

                • Afrow UK
                  Moderator
                  • Nov 2002
                  • 8434

                  #83
                  Uploaded v1.1. The callback is called initially before adding the custom item and then again every second after searching has completed.

                  Edit: And FYI Why do win32 calls GetModuleFileNameEx, EnumProcessModules, EnumProcessModulesEx fail in Wow64?
                  Edit 2: LockedList uses GetProcessImageFileName if it exists so LockedList will work for all executables (32-bit or 64-bit) but cannot work for 64-bit modules. One idea (which Process Explorer uses) is to run a secondary 64-bit process which relays information back to the 32-bit process (in this case, the plug-in) but this would be a lot of work.

                  Stu

                  Comment

                  • Animaether
                    Major Dude
                    • Jun 2001
                    • 1173

                    #84
                    Just tried, but the "LockedListCustom.nsi" example goes straight through without invoking the callback function, it seems. I'm using the regular DLL, MD5: 0dd1e0aee3b2aba0483c5d50c4656ba6

                    Re Edit: yeah, I found similar information a bit after I asked the initial question.. almost makes sense if not for it being something MSFT -could- have addressed if they really wanted to; alas

                    Re Edit 2: Right - I wouldn't delve into that right away

                    Comment

                    • Afrow UK
                      Moderator
                      • Nov 2002
                      • 8434

                      #85
                      Thanks, fixed. Reminder for future I must always test release DLL's as well as debug DLL's

                      Stu

                      Comment

                      • Animaether
                        Major Dude
                        • Jun 2001
                        • 1173

                        #86
                        Excellent - That is actually a pretty elegant solution to an entirely non-elegant problem.. makes LockedList extremely flexible as a sweet side-effect

                        One question if I may; the Custom example (which is still titled 'Using AddModule and notepad.exe' - btw) seems to use $R0 - the callback function address - 3 times. The docs only specify it once. I commented out the 2nd and 3rd and the example still runs so I suppose they're at least not required - but now I'm curious as to why they're there

                        *goes to hit the actual installer code to try and hook his simplified locked file check into this*

                        Comment

                        • Animaether
                          Major Dude
                          • Jun 2001
                          • 1173

                          #87
                          Sweet - as far as I can tell, this will work beautifully.. still have to test it in the wild, but several quick simple tests haven't revealed any particular problems.

                          So now I have...

                          ${LockCheck} : a simple locked files checker macro bit that only reports -if- a file is locked (if it exists, and if we care (version number check)), not -what- is locking it..

                          1. that I feed target/source files into with a single line call for each module
                          2. if it is determined none of the files are locked (based on the output of the macro), skip the LockedList dialog, otherwise...
                          3. initialize the LockedList dialog with those Module (32bit) or Custom (64bit) items that were determined to be locked, which will report the locking applications (32bit) and my Custom items (64bit)
                          4. which will automagically check everything except for the Custom items for which it calls...
                          5. a callback which invokes the simple locked files checking macro ${LockCheck} and...
                          6. tells lockedlist whether or not the file is unlocked based on its output again.

                          It's not perfect, but it's much better than going *BOINK* at a user mid-file installation with a can't-overwrite-this-file dialog

                          Comment

                          • Animaether
                            Major Dude
                            • Jun 2001
                            • 1173

                            #88
                            I just realized that when the dialog closes, the stack value for the next button is always "next" - which means you can't discern from it whether the user clicked the next (all apps were closed / there was nothing to close to begin with) or the 'ignore' button.

                            These are one and the same button just with custom captions on them, of course - which also leads to the work-around: grab the text off of the button and compare it to the '/ignore text' flag value you defined. Just thought it might be good if the plugin handled this in the value it pushes to the stack

                            Comment

                            • Afrow UK
                              Moderator
                              • Nov 2002
                              • 8434

                              #89
                              Done. Also added an IsFileLocked utility function. See the changelog for full details.

                              Stu

                              Comment

                              • Animaether
                                Major Dude
                                • Jun 2001
                                • 1173

                                #90
                                Sweet - seems you're on a roll
                                If IsFileLocked works well, I can replace the internal (FileOpen "path" "a") test.

                                At the moment, though, the Pop'ed value seems to be the passed "path" parameter?
                                ( I popped a few more time to different vars, they all seem to be null )

                                Comment

                                Working...
                                X