Well, I think I answered my own question after digging through the code...

I put into Debug Mode using the registry key. After confirming that nothing was changing the command to execute, I realized that the replacing for multiple files is only what's displayed in the context menu, not the commands being executed. So it looks like it will be a code change to append params rather than append commands to execute. I'll start thinking through the best way to code this. I'm also thinking that maybe there should be a way to exclude certain commands from displaying if multiple files are selected. Hmmm....

The more I dig through this, the more I think you're a genius Even 3-4 years later this application still holds up well.

Hey beaker! Things are going well, thanks. I do check in occasionally here, just to see what's happening.

Thanks for the appreciation of ContextAware! I still use it too, actually - though I haven't looked through the source for a while. In fact I haven't updated any of my stuff for ages - just not enough hours in the day

I really liked context aware - I think I'll have a looksie through the source and see what I can change. I always thought the config was the nastiest issue to handle, I might be able to clean that up a bit.

Also, I seem to remember it didn't handle shortcuts too well.

With respect to that last line about multiple files - I have no idea! I'm sure it made sense at the time though. Maybe it will make sense when I break out the source.

Hey back Thanks for the reply. I can really relate to the "not enough hours in the day" issue. I still want to look at this, I just haven't had a free moment lately. I'm trying to finish a lot of outdoor projects before Winter and it's got my free time down to slim.

I'm sure I'll look into this more seriously in the next 2-3 months, so if you haven't had a chance to yet, I'll let you know what I come up with. If you're interested in a play-by-play, send me a current email address, I'll keep you updated. If not, I'll post back here when I have something.

I've looked through the source, and you're right - the registry entries are only for localizing the display strings, nothing to do with the commands. One command is executed for each selected file, there is no way to group them

I've actually remembered what my plans were for the next version now; hopefully I'll find the time to implement them. Basically, for dealing with multiple files, shortcuts and complex conditions it would be nice to have an easier syntax, and the more I thought about the syntax the more I thought it looked like I'd have to write a basic scripting engine (even handling nested boolean logic isn't as easy as it looks). That's doable, but seems like overkill. So the idea that struck me was <looks around to see if anyone‘s spying> to actually host a scripting engine [WSH - so javascript/vbscript] and allow the user to write scripts to handle their own logic - as simple or as convolutedly complex as they like. Obviously, there would be some shortcuts for the easy cases, so people don't have to do scripting to get the functionality.

Then, of course, I started thinking “Why limit this to context menus?” Most shell extensions could be implemented this way [some more easily than others] so everything from HTML tooltips, icons, thumbnails, columns and property sheets could be scripted rather than programmed.

The downside to the scripting approach is that it would be much more difficult to write a UI configuration utility; which was part of the original plan (although the config would always be in hand-editable text files; I'm a big believer in that).

What are your thoughts on this? (btw, I've updated my profile so my email address is current)

That's a very interesting and innovative idea, I had to digest this one for a while before I replied. The clear upside to this is that it would be _extremely_ powerful and customizable. Users could create logic in whatever fashion and scripting language they are comfortable with. The biggest potential downside that I can think of is that scripts could impact performance negatively. I'm thinking of the fact that scripts are interpreted at runtime rather than precompiled, but this isn't any different than ContextAware reading text files at runtime and I've never seen a noticeable impact before. I think I'm eliminating this as a concern the more I think about it (I must still be digesting). OK, so if performance isn't a concern, than the other concern would be the magnitude of work to implement. I've never interacted with the WSH programmatically before, I don't know how difficult it would be. However, I _really_ like the thought of not reinventing the wheel on this, and letting the scripting host doing the legwork. I also like the fact that this would reduce the need for proprietary syntax.

Another idea just popped to mind as I typed "not reinventing the wheel", how about support for regular expressions? I'm not sure about VB, but they are very easy to implement in C#.

I agree that creating the UI configuration utility would be a PITA, but I think initially time is better spent making the engine more powerful before worrying about that. Once the backend stuff is ironed out, we could come back to it.

Hosting a scripting engine is easy as pie in VB, and not that much more difficult in C++ or even ASM. Honestly, this is really easy. For more so than writing one from scratch.

Being brought up on c++ and whatnot has made me naturally suspicious of the performance of scripting languages too — but it's not as if you're going to be doing image processing in script or anything. Simple logic evaluations like this should be no problem whatsoever. All the real menu functionality will be handled by compiled code — the scripts will just decide whether to add whatever items and what to do with them.

VB has no built-in support for regexps, but it can use the scripting engine's version very easily, so no problems there. I never got started in the whole .NET world, and since I'm doing mainly web work now, I'll stick to VB6/C++/ASM until I really need to migrate. But yeah, regexps will definitely be on the menu.

What might be a neat idea is to support most of the basic conditions normally, without resorting to scripting, and only use WSH as and when. Parsing ifs, elses, ands, ors and xors isn't really that complicated, even if they are nested, and that way the UI config can still happen. Bah, is it really worth it?

Another thing I want to handle with CA2 is modifying/deleting built-in menu items, in a similar way to mmm. As well as menu items with icons, of course!

I'll have a play over the weekend and see what I can come up with.

Wow, you've really got my interest! I really think "modifying/deleting built-in menu items" is an awesome idea. Like removing any Print command from the context menu?

It sounds like the scripting stuff will be easy too. Let me know what I can do to help.

Here, take a look at this preview:

http://files.shinyhappypixels.com/ContextAware2.zip

(source included, obviously)

Thoughts? Ideas? It's only a start, but it gets the point across.

Most downloads are blocked at my work. I'll take a look at it tonight...

Actually, if you have a second, can you make it a self-extracting zip? Sometimes I'm able to download exe's (which seems like more of a security risk to me). Otherwise I'll check it out at home

Sorry, don't have any software to create self-extracting exes. I've renamed the .zip to a .exe (same path otherwise) - give it a try [you'll have to rename it back to .zip after you download it).

Otherwise I could email it to you, if your work allows attachments. Alternately I can set you up an ftp account or something.

It seems to suffer the same problems on shortcuts though. I'll have to find a workaround for this. Works fine if you select a shortcut AND another non-shortcut file, then right-click the non-shortcut one.

:( It's still blocked as an exe. That security hole must have been plugged... Yeah, ftp is blocked as are email attachments.

Thanks for all your help. I'll have to wait to check it out until tonight.

Wow, we crossed paths on that post! I ended up creating rules to remove shortcuts (eg: '%file%.%ext%', '*.lnk', ^16) to get around that issue.

Can you think of a way to create a rule so that folder backgrounds can be turned off at will? I don't want to turn off the desktop, so I don't want to remove the registry key for all folder backgrounds, but still have some way to turn them off...

Sure, that's easy. In the zip there's one example script - pretty self-explanatory; here's the code:


if (IsBackgroundClick) {
  AddMenuItem("@Bg Click", function() { Alert("Folder background"); });
}
else {
  if (FileCount == 1) {
    AddMenuItem("@Single file", function() { Alert("Single file: " + FilePath); });
  }
  else {
    var files = [];
    for (var i=0; i<FileCount; i++) {
      files.push(FilePath(i));
    }
    AddMenuItem("@Multiple Files", function() { Alert(FileCount + " files:n" + files.join("n")); });
  }
}


(The @ sign is just for quick identification - it doesn't mean anything)

This sounds like an excellent idea. Not that it does anything on my machine, but I probably have WSH disabled or something.

Now that I'm finally home and able to test...Sweet!!! This is quite slick and shows a lot of promise. I'm impressed by how little code is needed to accomplish this. So far my only questions are:

• Are you planning on the matching being accomplished in script or handled by CA2 directly (or have options for both)?
• Will the window style be dictated at run-time in script then?

You continue to impress me Keep up the good work!

Like I said, this is just a taster - it will probably change quite a lot before its ready for user consumption.

Most of the matching will be done in the script, I think, although I might automatically add some wrapper functions for the hard of thinking. So for example:

// Define some function to return true if we want to process the file, false otherwise
function isInterestingFile(filePath) {
  if (filePath.indexOf('x') == -1) return false;
  try {
    var file = FSO.GetFile(filePath);
    if (file.Size < 1024 * 1024 * 10) {
      return false;
    }
    return true;
  }
  catch (e) {
    return false;
  }
}

// Then we do
if (MatchAllFiles(isInterestingFile)) {
  // something
}

// Or:
if (MatchAnyFile(isInterstingFile)) {
  // something
}

// Or even something like this:
var matchingFiles = FilterFiles(isInterestingFile);
if (matchingFiles.length > 0) {
  // ...
}

As for window style, I could write a wrapper to have an easy function, but I think I'll make a WScript.Shell object global as well as a Scripting.FileSystemObject. Its run method is quite versatile.

Actually, that would be a good part of the config: specifying what global objects to create for the script. It means that specifically-written stuff, like window management dlls or whatnot, could be pre-loaded if lots of scripts are going to access them.

I'm still not sure on the file structure. The basic thing I've decided on so far is to auto-load all .js and .vbs files in the /Script/ folder, but whether to automatically load files in subfolders is still up in the air - there are upsides and downsides to it.

Obviously [I bet you saw this one coming] there will be a config file per directory too (probably .ini - don't change a winning team).

Any ideas are welcome at this stage - before I run out of steam!

@craeonics:

That actually raises quite a good point - a lot of people do disable WSH for some reason, and this would be worthless to them. Hmm...

As far as testing it goes, all you should need to do is register the dll and merge the .reg file. If you've done that and it's not working then WSH is probably disabled.

I would be completely lost without WSH! I frequently write scripts to automate mundane tasks. (read: I'm lazy)

How about an entry in the .ini file whether to recursively load directories beneath it? That way the user can have control over what is preloaded, by where they place the script? You were probably leading me down that path, but I thought I'd state the obvious anyway

I like your idea of exposing some global objects. In fact, I'm realizing there's a lot that can be done with some coupling of code and script...

I'll try to come up with more ideas today.

Yeah, I'm the same; I use WSH a lot. Although for more intensive stuff I write in PHP which is great (very powerful), but most people wouldn't have php set up on their machine.

Also, my favorite editor uses WSH for custom scripts, which I couldn't live without.

I like custom scripts

I'm using Notepad2 still, and for teh most part I'm really happy with it. I wish it had a few more features, but you just can't beat it's speed. I just replace notepad.exe with it

However, there are times I wish I could do more, and in those siuations, I'd like a more full-featured editor. I'll have to give PSPad a whirl.

I use Ruby for scripting, but I don't script much (no need).

Back to ContextAware2 though, I do seem to have WSH enabled. I registered both DLLs and ran the install.reg file but nothing is happening (XP SP1). If I run the JS file on its own, I get an expected error (about a non-existing variable IsBackgroundClick), but I don't have additional context menu options or anything.

What am I missing? What is the demo supposed to do exactly?

Well, that's odd. You should be getting an extra context menu item.

Running the js file on its own obviously doesn't work, but registering the dll and installing the reg should activate the shell extension. Try right-clicking, then trying to delete the .dll - you shouldn't be able to because Explorer.exe will have loaded it. If you can delete it, something is wrong with the installation, if you can't (but still have no menu item) then there is something wrong with my dll.

Then something is probably wrong with my installation. I've registered both .dll's and I can delete ContextAware2.dll, but not ContextAware2.compatible.dll.

What is the purpose of the compatible.dll?

The compatible dll is just there for rebuilding the source. Without "binary compatibility" mode, VB6 will regenerate CLSIDs every time a dll is built, which would be annoying.

You don't need to register ContextAware2.compatible.dll - it wouldn't work anyway. Unregister that, re-register ContextAware2.dll, and give it another go.

Hi.

Mr. Grigri, thank you so much for ContextAware, it is one of my most used programs on a daily basis.
I don't know if this issue has been discussed already, but explorer crashes when I try to delete a shortcut, any shortcut, that has no valid target because the original file was renamed or moved.

Create a txt file, then create a shortcut from it and move it anywhere, then delete the base txt file and after that, try to delete the shortcut, and Explorer will crash if ContextAware is installed.
Uninstall ContextAware and repeat the procedure, and the shortcut will be deleted with no problems,

If theres any ideas on how can I resolve this, I will be very grateful.
Its just that I dont want to have to give up ContextAware for anything in the world.

Thanks in advance.

Hi Rhor

Yes, I'm aware of that bug - something I never got around to fixing. It shouldn't be that hard though.

I'll dig out the source and see what I can do... I still have VB6 installed on a machine somewhere!

You need to be logged in to post. To log-in, or to register an account go -there.