Browse for File Dialog ( W7)
in [VbScript]
|
Prev: AddWindowsPrinterConnection, but the mapping is NOT stored inthe user profile
Next: Changes made to Outlook form don't stay with form when mailed.
From: mr_unreliable on 28 Feb 2010 22:43 Kryten wrote: > I want to incorporate a browseforfile dialog box in my script. > hi Kryten, If you don't mind using a 3rd-party control, I recommend the CCRP (Common Controls Replacement Project) "Extended File Dialogs" actX object, by Domenico Statuto, found here: http://ccrp.mvps.org/index.html?controls/ccrpfiledlgdll6.htm The CCRP were a bunch of guys (sorry, no gals) who were so arrogant that they thought that they could do a better job of the common controls than ms. imho, they succeeded. cheers, jw ____________________________________________________________ You got questions? WE GOT ANSWERS!!! ..(but, no guarantee the answers will be applicable to the questions) p.s. if you don't mind using another scripting language, you will find that almost all of them have the open/saveas dialogs built-in to the language... p.p.s. if you don't mind calling the system api from script, (that requires another 3rd-party control) then you can instantiate the open file dialog directly.
From: mayayana on 28 Feb 2010 22:41 > If you happen to have ms's Common Dialogs control (comdlg32.ocx), > then you could use that: > It's not enough to have it. That's a licensed control. You have to have a license. So if a script is running elsewhere than just locally (with a license) then comdlg32.ocx doesn't make much sense. Most people don't have it and/or can't use it. (Some people may have it because it was installed by specific software, but in that case only the installed software has the license to use the control.) Given that, a 3rd-party control would be a much better choice. It has the disadvantage that it must be delivered to and registered on the target. But it can, at least, be used on all targets.
From: mayayana on 1 Mar 2010 00:21 > If you don't mind using a 3rd-party control, I recommend > the CCRP (Common Controls Replacement Project) "Extended > File Dialogs" actX object, by Domenico Statuto, found here: > > http://ccrp.mvps.org/index.html?controls/ccrpfiledlgdll6.htm > You sure do have a way of giving people confusing answers. You seem to delight in providing obscure, tricky, or even irrelevant options. Why do you send people on a wild goose chase? There are lots of free components designed for script. I've written two myself that have File Open dialogues: http://www.jsware.net/jsware/scripts.php5#brows http://www.jsware.net/jsware/scripts.php5#jssys I expect there are probably several others to choose from. Yet you provided a link to a fairly complex library that's not designed for script, after first suggesting a control that needs a license, without explaining that it needs a license. Do you *like* to confuse people? The DLL you linked is not designed for scripting. It uses events and strict data types. I didn't try a test script myself. It looks like it would be a fair amount of work just to see if it's usable. If you know that it does work in script then it might help people reading this thread if you'd at least post some sample code.
From: Kryten on 1 Mar 2010 03:06 Thanks to everyone who replied. I have issues with the browseforfolder method. I had experimented with it before actually and was able to get it to expose files, OK but it always emits an error after selecting one of them. Never able to properly update the OpenfileDialog.Filename property. The IE method, for me runs but does not result in a filebrowser. Deconstructing the code I can certainly get the IE about:blank to show but the underlying functionality isn't there. Maybe because I'm using W7/IE7? Not sure. The jsware stuff looked really promising until I got the "Windows Vista is not supported exception". Looking around the jsware site it looks like I may be out of luck using these controls in Vista and W7 ;-) This may not be too much of a problem right now as the desktops I'm developing the script for all run XP/SP2 and will do till the end of this year. My scripting language of choice is actually Powershell, where thanks to applications like ASE and PrimalForms it's trivial to create Windows Forms Applications. It also makes instantiating .NET objects easy too. Such as $browse = new-object system.windows.forms.openfiledialog Any ideas, or boilerplate code for using that .NET object in VBScript ( Once it gets > 100 lines I lose interest though! ). Thanks again, Stuart
From: mayayana on 1 Mar 2010 09:35
> The IE method, for me runs but does not result > in a filebrowser. Deconstructing the code I can > certainly get the IE about:blank to show but the > underlying functionality isn't there. Maybe because > I'm using W7/IE7? Not sure. > Interesting. I'll have to do some testing. I think I've used it in XP with IE8, but I'm not certain. You used essentially what I posted? The IE window is not supposed to show. You're supposed to just get a File Open window. That's the nice thing about it. The fact that it's an IE hack is not apparent. But it is limited. You can't assign a filetype filter, etc. > The jsware stuff looked really promising until I > got the "Windows Vista is not supported exception". > Looking around the jsware site it looks like I may > be out of luck using these controls in Vista and W7 ;-) > Woops. Sorry, I forgot about that. If you need it for Vista/7, though, you still should be able to find options. The actual Win32 API code to show a browsing window is minimal, so it's easy to wrap it. > > Any ideas, or boilerplate code for using that .NET object in > VBScript ( Once it gets > 100 lines I lose interest though! ). > .Net is not COM-based, unfortunately, so most of it is not usable by VBS. You might check in the ..Net or powershell groups, though. Maybe something can be worked out. It would mean a massive dependency, but probably not an issue if you only want it for in-house use. If you're also willing/able to use .Net you might be able to wrap the object in Interop for script. I don't know much about .Net myself, but as I understand it there's something they call Interop (I don't know what it involves) that can serve as an interface between .Net and COM. The whole thing would be rather clunky: .Net serves as a superfluous wrapper around the system, which is mainly COM. But .Net is not directly COM-compatible. So Interop allows the wrapper to connect back to COM again. Then script gets indirect access to that via WSH. :) But it's only a File Open dialogue, so it's not as though there'd be a performance issue. |