LockedList plug-in

LockedList::IsFileLocked doesn't show the UI. It is purely a utility function to avoid having to use FileOpen (it does that internally).

Edit: I will sort that bug/typo later 🙂

Stu

This is a codec filter binary with extension ".ax" . This codec filter is installed by my application as well as ,it will be shared by some third party applications. Hence the need , to detect whether this is locked or not when I reinstall or upgrade my application .
I tried the IsFIleLocked function , but it did not appear to sense it was locked.
Is this a bug as Stu pointed out?

You mean IsFileLocked always returns false? Does FileOpen work (follow jpderuiter's link)?

Stu

Yes that is what is happening.
BTW, this being a binary file will FileOpen work?

FileOpen (CreateFile) works on any file. Try it.

Stu

Yes FileOpen code snippet from the other forum worked as expected.
What is the issue here

Show me the LockedList plug-in code you are using. As I said, my plug-in code is the same as using FileOpen so you must be doing something wrong.

Stu

Originally Posted by Afrow UK View Post

My plug-in code is the same as using FileOpen

I don't think it does, though?

From an earlier discussion (same thread):

Originally Posted by Animaether View Post

confirming the IsFileLocked bugfix. Unfortunately it doesn't recognize the locked DLL as being locked

Originally Posted by Afrow UK View Post

Yep it will only work on files that have a handle open on them (DLL's do not when they are locked)

So given that...

Originally Posted by Alfaromeo View Post

This is a codec filter binary with extension ".ax"

...wouldn't it be subject to the same difference?

Originally Posted by Afrow UK View Post

Show me the LockedList plug-in code you are using.

Just in case there -shouldn't- be a difference after all, the following example should work to demonstrate:

!addplugindir "."
!include "nsDialogs.nsh"
OutFile LockedListTest.exe
Section
SectionEnd
Var dialog
Var hwnd
Page Custom test
Function .onInit
  InitPluginsDir
FunctionEnd
Function test
  nsDialogs::Create 1018
  Pop $dialog
  ${NSD_CreateButton} 0 0 100% 10% "Use LockedList"
    Pop $hwnd
    ${NSD_OnClick} $hwnd button.lockedlist.onclick
  ${NSD_CreateButton} 0 20 100% 10% "Use FileOpen"
    Pop $hwnd
    ${NSD_OnClick} $hwnd button.fileopen.onclick
    
  nsDialogs::Show
FunctionEnd
Function button.lockedlist.onclick
  Pop $hwnd
  LockedList::IsFileLocked "$PLUGINSDIR\nsDialogs.dll"
  Pop $0
  MessageBox MB_OK "$PLUGINSDIR\nsDialogs.dll$\r$\nLocked: $0"
FunctionEnd
Function button.fileopen.onclick
  Pop $hwnd
  ClearErrors
  FileOpen $R0 "$PLUGINSDIR\nsDialogs.dll" "a"
  IfErrors _errors _noerrors
  _errors:
      StrCpy $0 "true"
      goto _done
  _noerrors:
      StrCpy $0 "false"
      FileClose $R0
      goto _done
  _done:
  MessageBox MB_OK "$PLUGINSDIR\nsDialogs.dll$\r$\nLocked: $0"
FunctionEnd 

Thanks, both issues should be fixed. For some reason I had omitted GENERIC_WRITE on CreateFile (in IsFileLocked) so I am suprised IsFileLocked ever worked at all.

Stu

yay 🙂

Any thoughts on that Ignore button bit? (custom Ignore text not getting cleared once list is empty)

It works now. Possible to get a array of processes that is being used by the concerned file if locked. Will be helpful for me to display the same in the MessageBox and take user action.

@Animaether
Ah didn't see that one sorry. There's no code in there to set it back so I will add it when I have time.

Stu

Stu,

I acheived my option , by using the SilentSearch option from the examples listed.

Although I have listed another query sometime back in this forum , was not answered. Is their any option to give search path , instead of individual files. This will ease listing files one by one

Currently only files are supported but I will add this when I have time (AddFolder). Got exams coming up so I can't promise anything soon!

Stu

Originally Posted by Afrow UK View Post

There's no code in there to set it back so I will add it when I have time.

Cool - thanks 🙂

Originally Posted by Alfaromeo View Post

Is their any option to give search path , instead of individual files. This will ease listing files one by one

Nope - I wouldn't recommend this, either.

Let's say you need to overwrite a few files in 'c:\windows\'... would you honestly want to feed LockedList 'c:\windows\*.*' and have it throw up pretty much every locked file.. even though you might only want to overwrite two of them?

I think your best bet is to create a list of the files you want to overwrite - either by A. hardcoding this in the installer by hand or by a pre-installer build-installer or B. extracting your files to a temporary location and use any of the FindFirst / FindNext / bits and pieces - and feed that to LockedList

The 'B' method could be combined with lockedlist directly.
i.e.

for each destination path (

  extract the files that go to a certain path to a temporary location

  loop over the extacted files, and for each file (

    add the 'destination path\filename' to LockedList

  )

)

The temporary location can be re-used with e.g. CopyFiles to get the files to the destination path without having to re-extract them from the installer.

You're better of generating the LockedList AddFile/AddModule code at compile time using Locate in a specially built NSIS executable that you execute with !system (see http://nsis.sourceforge.net/Invoking...n_compile-time). However, I think AddFolder would be fine when used properly (i.e. your application's path that you may wish to completely remove).

Stu

@Animather

I understand the complexity involved if AddFolder ( proposed function by Stu) is not used properly. As rightly said , using it on C:\Windows or any system related folders can be an issue. If we know what folders or files that are going to be targeted , this is not an cause of worry .

@Stu

This function if developed can ease my application's perfomance, because the application can cause any of the files in the instalation directory to be locked. Hence looping over and using AddFile is an existing option, but an overhead.

'AddFolder' true, fair enough for self-contained areas 🙂

Uploaded v1.6.

v1.6 - 4th June 2010
* Fixed processes getting repeated in the list.
* Fixed list not auto scrolling to absolute bottom.
* Next button text restored when using /ignore and no processes are found.
* Added AddFolder plug-in function.
* File description displayed for processes without a window caption.
* Process Id displayed for processes without a window caption or file description.

Stu

Thanks Stu,
Indeed, processes were repeated in the list. Nice, that this is fixed now.
I will test new build as soon as possible.
-Pawel

[Edit]
Stu, Please add version information to dll, in next build (for Embeddedlists.dll too)

v1.7 - 8th July 2010
* Process file description now retreived by SystemEnum if no process caption found.
* Added EnumProcesses plug-in function.
* SilentSearch now uses a callback function instead of the stack.
* SilentSearch /thread changed to /async.
* Previously added processes now stored in an array for look up to prevent repetitions rather than looked up in the list view control.
* Added FindProcess plug-in function.
* Now gets 64-bit processes (but not modules).
* RC2: Added version information resource.

Stu

Stu,
New version 1.7 doeasn't close finded applications (searching is OK, but when I clik Next button, I got message, "Cant close applications...".)
v1.6 did it correctly.
-Pawel

It is really a good plugin. But I found that the icons in the listview is not the small one of a executable file but a zoomed one of the big icon (32x32). The zoomed icon doesn't look as good as the original small icon of the executable file. So I modified the source code, using ExtractIconEx function replace with ExtractIcon.

Before:

After:


Attachment is the modified source LockedList.cpp.

Nice one. I will update the plug-in.

Stu

Sorry for my poor English, I should say "using ExtractIconEx function to replace ExtractIcon".

Besides, line 1660 was incorrect, I typed a blank in the word "image" by accident when modifying:
hIma geList = ImageList_Create ...

Expecting your next version.

I have uploaded v1.9. I had a look at your code - there is no need for a global variable.

Stu

Yes, I am so folly, the variable is exactly unnecessary.
I have downloaded the new version, it is very good!

I have found some unicode build issues while building GetVersion which will likely apply to LockedList (partly due to migrating to VS2010). Will fix and reupload soon.

Stu

Done. Unicode build was indeed faulty.

Stu