PDA

View Full Version : Filter Problem



NewsArchive
06-01-2013, 03:40 AM
A small problem has happened since I have installed SetupBuilder Developer
2013 Version 8.0.4063. When I now do a static scan all the windows dll’s are
showing to be included in the project. I have included them in the
userscan.ini and some of them are also included in the sbscan.ini file. I am
running Windows 8 Professional 64 Bit.

Any help would be gratefully appreciated

TIA

Trevor
Simple Computing

NewsArchive
06-01-2013, 03:41 AM
Trevor,

Nothing changed in this feature for 5 years (February 2008). The static and
dynamic scan DLLs are the same in SB6, SB7 and SB8.

Friedrich

NewsArchive
06-01-2013, 07:43 AM
BTW, just a quick idea. I think what you see are references to the 64-bit
components (e.g. c:\Windows\System32\KERNELBASE.dll).

You have to run Notepad.exe elevated (very important!) and open
"userscan.ini". Then you can add the file(s) to be excluded to the
"userscan.ini".

Friedrich

NewsArchive
06-01-2013, 07:44 AM
Will this work in 32-bit? I'd like to exclude anything in the windows
folder, or rather listed but unchecked.

Also, if a resource is listed in the scan and already exists in the
target list, I'd like the Add button to overwrite existing entries.

I use the scan feature a LOT and the above two would just put a bit of
nice polish on that feature.

--

Russ Eggen
RADFusion International, LLC

NewsArchive
06-01-2013, 07:44 AM
Hi Russ,

> Will this work in 32-bit? I'd like to exclude anything in the
> windows folder, or rather listed but unchecked.

Unfortunately, this will not work. I'll see if it is possible to add some
kind of "wildcard" option to the filter. For example, "c:\Windows\*" to
exclude anything in the Windows folder. This would make sense because you
should never deploy anything from the Windows folder tree today.

> Also, if a resource is listed in the scan and already exists in the target
> list, I'd like the Add button to overwrite existing entries.
>
> I use the scan feature a LOT and the above two would just put a bit of
> nice polish on that feature.

If a resource is listed in the Scan and it already exists in the target list
then that item is skipped (because the very same location already exists and
there is nothing to overwrite). But there is a bug in that feature (which
might never be fixed):

http://www.lindersoft.com/forums/showthread.php?t=5325

The Scan Wizard will also add a duplicate item if the source locations for
the same filename are different. But this scenario is very unlikely. In
most cases (and in all modern applications), EXE files and statically linked
DLL files are located in the same folder.

Friedrich

NewsArchive
06-01-2013, 07:45 AM
I have attached a demo "USERSCAN.INI" for a standard application on Win8
x64. The exclude list depends on the components used.

Hope this helps.

Friedrich

NewsArchive
06-02-2013, 07:14 AM
Hi Friedrich

That helped. Many thanks. I used the clipboard function in the "filter
window" and pasted that into the userscan.ini. The only difference I can
tell is that it still had the folder names in front eg c:\windows\system
etc. Have to try and remember for next time lol.

Thanks again

Trevor

NewsArchive
06-02-2013, 10:48 AM
Friedrich,

The problem here is the source location. It very likely no longer
exists (esp with files shown as 0 bytes). This is the case when I
inherit someone else's script, or start changing folders around. If
this could be on the file name itself, then I think this may be easier
for you to detect (he says having never seen the source code <g>).

An exclusion filter might work on the other matter, but this sounds like
a lot of work for you. Since the results are in a list with a checkbox
ticked, there has to be code somewhere to set it. Just from a pure
logic standpoint, would it not be easier to unset (or not set it in the
first place) the check as windows items are added to the list?

--

Russ Eggen
RADFusion International, LLC

NewsArchive
06-03-2013, 12:43 AM
Russ,

Aha, okay. Yes, this makes perfect sense :-) I'll see what I can do.

Thanks,
Friedrich