Border sandboxed indicator
Version 3.33.14 includes this functionality, which you can enable from Sandbox Settings > Appearance.
It's a bit less configurable than your utility, Micahs, in that you can only configure colors but not border thickness or the level of transparency/opacity.
I really like how you implemented this using an overlaying window, very clever.
It's a bit less configurable than your utility, Micahs, in that you can only configure colors but not border thickness or the level of transparency/opacity.
I really like how you implemented this using an overlaying window, very clever.
tzuk
Are you planning to eventually support those things? Right now, I find the default border way too thick and somewhat too transparent.tzuk wrote:It's a bit less configurable than your utility, Micahs, in that you can only configure colors but not border thickness or the level of transparency/opacity.
Just FYI, a minor bug was introduced with this. If I enable the "Display a border around the window" option, I can no longer disable it via the settings GUI panel. In fact, if I just unselect that box and click Apply, the check mark immediately reappears again. The only way I could disable it was to manually delete the "BorderColor=#00FFFF,n" line in Sandboxie.ini.
@Micahs: Any progress on getting all windows to stay highlighted even when not in focus? tzuk's current implementation doesn't do that either, and I'd really find that extremely useful. Thanks!
BorderGuard Redux
Hi there.
I downloaded the beta version and the AutoHotkey script a few days ago. Even when I found the script much more versatile than the built in solution, I still felt it lacked a couple of features. So I coded up my modifications taking Micahs' script as a base; I called the resulting abomination I'm happy to present to you "BorderGuard Redux".
Screenshots:
None at the moment, but it's sort of pointless, since it looks pretty much like plain BorderGuard.
Features:
Download
You can get the latest version (0.1) here: http://rapidshare.com/files/178880927/B ... _Redux.zip
Please note: First and foremost, I never intended to "hijack" Micahs' script or anything, just trying to make it cope with what I (whimsically) expected it to do, so, Micahs, if you'd like me to unlink the file, start another topic, whatever, just say so, there's no problem there (BTW, great script indeed!). Secondly, I took Micahs' script as a base to make this one, that means that if you like it you should be thanking him, and if you find any bugs you should be blaming me. Last but certainly not least, huge kudos go out to tzuk for making this incredible app!
Regards.
PS: needless to say, comments are most welcome.
I downloaded the beta version and the AutoHotkey script a few days ago. Even when I found the script much more versatile than the built in solution, I still felt it lacked a couple of features. So I coded up my modifications taking Micahs' script as a base; I called the resulting abomination I'm happy to present to you "BorderGuard Redux".
Screenshots:
None at the moment, but it's sort of pointless, since it looks pretty much like plain BorderGuard.
Features:
- The script will get sandbox names directly from Sandboxie's ini file.
- The script can be configured to terminate itself when SbieCtrl finishes.
- Enable or disable border highlighting by default for new sandboxes.
- "Hide on drag"'s default now depends on whether the user selected "Drag Full Windows" or not.
- The corner's style can be specified for all four corners individually (that is, you can have 2 of them rounded whilst the other 2 are straight).
- Support for taking "interior radius" into account (in some visual styles the window's corners are rounded, this setting allows for that fact to be taken into account, thus not overlaying the actual window with the border).
- The amount by which borders are offset towards the middle while the window is maximized can be specified for the four sides independently.
- Support for taking "size corrections" into account (in some visual themes the window looks smaller/bigger than the size it actually reports).
- When the icon is hidden it can be shown back by pressing Win-G (this will not be saved into the configuration file, its just to access the icon's menu, it can be hidden again by reloading the configuration).
- New option to simply reload the configuration.
- After editing the configuration file, the settings are automatically reloaded.
- The code to draw round borders has been rewritten (not sure if it looks/performs better/worse, feedback regarding this is appreciated).
- You need to adapt your existing ini file (this shouldn't be too difficult).
- There are a couple of dependencies:
- The stringconverter tool program (you can get it here: http://www.gbordier.com/gbtools/stringconverter.htm). This can be copied anywhere, if the script can't find it in the "res" directory it will prompt for it. (This program is used to turn a temporal copy of Sandboxie.ini fron Unicode to ANSI, since AutoHotkey doesn't do Unicode yet).
- The CmnDlg 4.1 --- Common Dialogs AutooHotkey script (you can get it here: http://www.autohotkey.com/forum/topic17230.html). This should be placed in the "res" directory. (This script is included by mine, so the script won't even start if you don't have it, it's used to display slightly more configurable open dialogues).
- I just arrogantly killed the "[Localization]" section of the ini (don't have a very good reason for this one, it should be fairly easy to bring back though).
- For some reason, when there are only two visible windows, one sandboxed and one unsandboxed, and the unsandboxed window has focus, clicking on the taskbar to minimize the unsandboxed window and, thus, give focus to the sandboxed one, produces a nasty flickering of the sandboxed window border (ideas regarding this weird bug are most appreciated)
- Bring back localization (most doable, I'm just too lazy to do it right now).
- Make the cornerRadius setting take the four corners into account independently (maybe).
- Remove CmnDlg dependence (doable, yes).
- Make it so that an image instead of a plain color can be selected as border (this opens up a couple of problems, tiling vs stretching for instance, but I think it could be done and greatly improve the effect. Ideas and/or help regarding this are very much appreciated).
- Make a configuration interface (not likely to happen, since I can't do GUIs in AutoHotkey to save my own life).
Download
You can get the latest version (0.1) here: http://rapidshare.com/files/178880927/B ... _Redux.zip
Please note: First and foremost, I never intended to "hijack" Micahs' script or anything, just trying to make it cope with what I (whimsically) expected it to do, so, Micahs, if you'd like me to unlink the file, start another topic, whatever, just say so, there's no problem there (BTW, great script indeed!). Secondly, I took Micahs' script as a base to make this one, that means that if you like it you should be thanking him, and if you find any bugs you should be blaming me. Last but certainly not least, huge kudos go out to tzuk for making this incredible app!
Regards.
PS: needless to say, comments are most welcome.
Re: BorderGuard Redux
Sorry, I was the one who wrote the previous (BorderGuard Redux) post, I just timed out.
I have most of multiple-sandboxed-window-highlighting done. I just have to work out some small issues and incorporate it into the main borderGuard program.
Sneak peak:
I need to make it pretty and there's some problem with windows that are sandboxed but do not have the sandbox class tag (Open/Save dialogs, etc.) Also, the new method displays the border window behind the sandboxed window, so maximized windows have to be handled differently. I have some stuff to do yet, but it's coming along!
"I never intended to "hijack" Micahs' script or anything" - No worries!
Sneak peak:
I need to make it pretty and there's some problem with windows that are sandboxed but do not have the sandbox class tag (Open/Save dialogs, etc.) Also, the new method displays the border window behind the sandboxed window, so maximized windows have to be handled differently. I have some stuff to do yet, but it's coming along!
"I never intended to "hijack" Micahs' script or anything" - No worries!
Yay!Micahs wrote:I have most of multiple-sandboxed-window-highlighting done.
Hasn't this always been a problem though - regardless of whether or not there is multiple highlighting? I've often seen windows like that not handled properly. Didn't seem to be the program's fault though since even the taskbar entry didn't show the "[#]" tags. Obviously Sandboxie still knows they are sandboxed though since the Sandboxie tray icon changes anyway. Maybe you can queue off whatever Sandboxie queues off to tell that icon to change?Micahs wrote:...there's some problem with windows that are sandboxed but do not have the sandbox class tag (Open/Save dialogs, etc.)
That should look much better than the current method. Plus it may be more friendly with various non-default desktop themes.Micahs wrote:Also, the new method displays the border window behind the sandboxed window...
Thanks!
The problem is not detecting the sandboxing because I keep a list of sandboxed processes and compare the process of the window to that list. The problem is that the border of the owned window will, in certain circumstances, fall behind the parent window. I'm not exactly sure why this is.
It is still coming along well. I'll upload it soon.
It is still coming along well. I'll upload it soon.
Well, I don't actually loop through all processes and determine which are sandboxed. What I do is loop through all visible windows and check the class name for the "Sandbox:XXXX:" telltale. If found, I get the PID of the window and add it to a list for later. If not, I check if the process of that window is in the "sandboxed process" list. Either way, if sandboxed, I display the border.
This way, I can tell if the window is sandboxed or if it is owned by a sandboxed window. As far as I can tell, this way is foolproof. I have not noticed any slipping through, anyway!
If you have a better way, I'd love to hear it. Any way to simplify or speed up the thing is always good. Regardless, what is your method?
This way, I can tell if the window is sandboxed or if it is owned by a sandboxed window. As far as I can tell, this way is foolproof. I have not noticed any slipping through, anyway!
If you have a better way, I'd love to hear it. Any way to simplify or speed up the thing is always good. Regardless, what is your method?
If you're talking about using 'Start.exe /listpids' then that is probably the best and fastest way. My other idea was using EnumProcessModules from PSAPI to look at each process and see if SbieDll.dll had been loaded. While that's probably better than looking at window titles or classnames as far as reliability, using /listpids would certainly be faster.
Micahs, not completely foolproof. If Sandbox Settings > Resource Access > Window Access has a setting for * (a single star) then there is no Sandbox: prefix for the class names.
wraithdu, you would probably need to run Start.exe /listpids fairly frequently, probably every few seconds, I'm not sure it's a good idea.
If you guys know how to call a function exported by a DLL, then you can load SbieDll dynamically and call one of its API functions to enumerate sandboxed processes. I can elaborate if you wish.
wraithdu, you would probably need to run Start.exe /listpids fairly frequently, probably every few seconds, I'm not sure it's a good idea.
If you guys know how to call a function exported by a DLL, then you can load SbieDll dynamically and call one of its API functions to enumerate sandboxed processes. I can elaborate if you wish.
tzuk
Who is online
Users browsing this forum: No registered users and 1 guest