Er, sorry that is the INPUT TYPE="FILE"... forgot to leave out the brackets....

Oh yeah, I'm also trying to define the location that it opens first. Preferably Relative to the html document.

Check out this thread; while not HTML-specific, it might help

please use edit in the furture

DOH! Sorry, didn't see the edit button for some reason.
Unfortunately that thread relied heavily on a little app written by Grigri. I cant use an external app for this easily. This is an HTA in progress, and although I belive HTA's have less restrictions on File Access, I have yet to fire off an application without an alert message popping up. (This could be because the function isn't firing from the "Root" HTA, and is firing form a framed .HTML.... perhaps if i framed an HTA inside of the HTA.... I'll have to try that.) Although I have RunProtocol Handler installed, I cant expect my clients to. So I am searching for some way to:
A: Force a FILE tag to spawn the browse window in a pre-determined folder (Preferably Relative to the spawning HTML document.)
B: Either force the targeted folder to view by Thumbnail as default (even after being burned to CD) or force the spawned Browse dialoge to default the view to Thumbnail.
Both of the above must be acomplised by a method that does not require the user to install something else. I don't even know if it's possible, but you guys often re-wire my understanding of what is possible within windows!

Thanks for the reply, gave me some ideas!

Ozone.

hmm. MSDN' database on HTAs had something about allowing framed HTAs access to same permissions as the root. I'll search for the link and post it later.

About HTA frames security policies:

See MSDN reference here.

hmm... could you embed a common dialog controller into your hta code and do the browsing thing manually? That's about the only way you'll make it work without an external component.

Thining of that, you'll probably have some external files; images if nothing else. Why not have a small COM dll as well? The user wouldn't have to do anything, the script would register/unregister it automatically when needed. This way you could have a process-specific version of Viewtify [I'll rewrite it as a component].

There might be other ways, but those 2 are all I can think of for now...

Woah, tweaking dll's is a bit beyond my ability yet Grigri. I'm just a web designer who's getting sucked into the OS specifications because I'm writing a program outa HTML. What your recomending would be a file that resides with the HTML document? And how would I activate it?

Well, assuming the dll is called "ViewtifyCOM.dll" and the component is called "ViewtifyCOM.Viewtifier" you'd do it like this:


// Called during initialization (Window's onload event)
// First, register the dll using regsvr
var WshShell = new ActiveXObject("WScript.Shell");
WshShell.Exec("regsvr32.exe /s ViewtifyCOM.dll");

// Create the viewtifier
ViewtifierObj = new ActiveXObject("ViewtifyCOM.Viewtifier");
// Attach it to this window object (this will set up the dialog hook)
ViewtifierObj.Attach(document.window);
// Set the parameters
ViewtifierObj.SetView("Thumbnails");
ViewtifierObj.SetInitDir("c:\\some\\folder\\of\\your\\choice");


Of course, I'd have to write the dll first, but that would be how it would work. Alternatively I could write an ActiveX control replacing the <input type="file"> that allows more control, in which case it would be like this:


<!-- inside page markup -->
<object id="ViewtifyObj" classid="clsid:22D6F312-B0F6-11D0-94AB-0080C74C7E95"/>

// Inside window.onload event handler
ViewtifierObj.SetView("Thumbnails");
ViewtifierObj.SetInitDir("c:\\some\\folder\\of\\your\\choice");


The second solution seems better, although if you are planning to use the filename in a <form> sumbission (GET or POST data) is would require further tweaking [probably creating an <input type="hidden"> or <input type="file" style="display: none"> field and keeping the data synchronised between the two objects... interesting problem.

Grigri,
The second idea definately sounds like a winner. I am already transfering and filtering the data generated by the FILE field. (The user browses to a location, and returns file://C://TheProgram//Images//TheImage.gif .. The script strips it all down to TheImage.gif, since there is only one folder they are supposed to put images in. This is also why I am so keen on locking down the original folder when Browse is activated.)

So would your second suggestion basicaly reside as an HTML document, seen as a ModelessDialoge window spawned by the parent document?

Thank you soooo much for your help on this.

The Noob without a clue:

-Ozone

Okay, how about a different approach.... is there a way to pull a folders contents into a variable somehow with JavaScript? If I could do that, I could manufacture my own browse window.

Sure, that's easy - either use the FileScriptingObject or the Shell.Namespace (depending on whether you want real directories/files or part of the virtual namespace). Well, retrieving the file/folder names is at least easy... getting a context menu or an icon is another matter.

I've uploaded an experiment I was working on to redo the start menu in HTML. I never finished it, but it's not that long and should give you a few pointers.

MenuHTML.zip [3KB]

I've done a quick 'n dirty image selection dialog:
PicBrowseHTML.zip [2KB]

OMG! Thanks Grigri! This has EXACTLY the code I need! The start menu will come in handy too! Thank you sooo much!

If you can get proper scrollbars working in the dialog [one in the folder list, one in the picture list], please tell me how - I couldn't get them to work.

Also don't forget that the FSO treats "Drives" and "Folders" differently, which is why you can't change or browse drives with this code, to enable that will require a little tweaking.

Change Line #139 to this:

<div id="divFiles" style="overflow-x:hidden;overflow-y:auto;height:440;width:100%">File List</div></td></tr>

And #137 to this:

<div id="divFolders" style="overflow-x:hidden;overflow-y:auto;height:440;width:100%">Folder List</div></td>

The "Auto" on overflow is IE specific, but then again, so is all the FSO stuff.

Thanks Again!!

Ok grigri,
I spent the morning beating the tar outa this Image Browser! (Lotsa Fun too!) I added some functionality to it. I tries not to distort smal images as much, and It includes an "UP" button. I added some grapics for the GUI, and VOLA.... I admit, it resembles the Microsoft shell, but that was my intent. It is still PLENTY flexible as far as that goes!

I was kinda hoping you might take a few more whacks at it now, and perhaps add drive navigation. But even if ya don't, it don't mater, it is COOL! And exactly what I needed!

Here is the modified file: http://home.comcast.net/~alphaeight/ImgBrowse.zip

This seems like a really neat thing, but alas I cannot think of what I could use it for.

Heh MagnetMan, perhaps it can help those who ditest the inability to change the "Browse" button on a File Tag!

Actualy grigri, do you have a line of code that will just make a string based on the local drives.... something like:

"A:,C:,D:,E:,F:" ?

If I had that, I could do the rest. =)

Sure, no problem. It's actually pretty easy using the FSO.

function ShowDriveList()
{
  var fso, s, n, e, x;
  fso = new ActiveXObject("Scripting.FileSystemObject");
  e = new Enumerator(fso.Drives);
  s = "";
  for (; !e.atEnd(); e.moveNext())
  {
    x = e.item();
    s = s + x.DriveLetter;
    s += " - ";
    if (x.DriveType == 3)
      n = x.ShareName;
    else if (x.IsReady)
      n = x.VolumeName;
    else
      n = "[Drive not ready]";
    s +=  n + "\n";
  }
  return(s);
}
Basically, the Drives collection is used in the same way as Folders. More info here.

Bravo on the scrollbars btw. Sometimes my logic and the microsoft HTML team's logic seem incompatible...

MagnetMan, since there is more and more HTML in the GUI [toolbars, appbars, active desktop, ...] and with the advent of HTAs it's quite feasible to do small applications entirely in HTML. With this component [hmm.. better re-write it as an actual component] you could allow the user more interactivity [selecting skin files, picture elements] that would have been difficult before, especially with this level of customization. The original thought behind this was just to set the view to thumbnails and set the starting directory, which was pretty much impossible with the <input type="file"> tag. I think it's a good thing

Super! Hey, is there a way I can retrive the full path for the local folder than an HTML / HTA is in? That will allow this widget to know right where to look for the images.

Well, unescape(location.pathname) will give you the pathname of the HTA file itself, so you could use:

var fso = new ActiveXObject("Scripting.FileSystemObject");
var f = fso.GetFile(unescape(location.pathname));
var fldr = f.ParentFolder;
alert("Folder is : \n" + fldr.Path);

Oh, and did you notice I've replied to your other HTA thread about cross-frame scripting in HTAs?

Mmm...
I get an Error "File Not Found" with this line:
var f = fso.GetFile(unescape(location.pathname));

:/

Yes, I noticed the other post. I actualy found a "workaround" for the problem (a looping monitor for the non Aplication page... does a filesave if the monitored variable contains data) but I didn't want to keep a thread going if it wasn't neccisary...

Er... Nevermind... didn't put it in the top-level of the HTA... works great

Anybody know how to make the associated Icon on an HTA show up in explorer when the folder is viewed? Right now it is a standard "unknown" icon.
Thanks.

Wierd... works fine here. Use alert() to make sure location.pathname is filled properly - the unescape() function translates the %20's to spaces and so forth.

HTAs don't have an 'associated' icon, as such. The registry points to C:\WINDOWS\System32\mshta.exe,1, but mshta.exe doesn't contain any icons on my system. If you want to give them an icon, just use regedit to change this value:

HKEY_CLASSES_ROOT\htafile\DefaultIcon

I could also write an Icon Handler for hta files, which would attempt to read the ICON attribute in the <HTA:APPLICATION> tag, use that if specified and use the default if not. Anyone interested?

I'll kep the registry data in mind, thanks Grigri! You're the best. I bashed the widget around some more with the drive functionality, and got a nice working model with full browsing capabilities.

Also, I made it so the spawned file could be run solo.. but the results all stay in the same window (try it out to see what I mean). I also made an HTA based off of the popup.. so check that out to.

As for the Icon handler... probably no point unless more people than me need it. I'd find it usefull, but I'm the most active with HTA as near as I can tell. Plus, I really just want something "clickable" off the root of a burned CD that will launch my HTA (which will launch by itself when clicked just fine), which ALSO has my applications ICON. Would a .lnk file work for that? Or would the arbitary Letter possibilities for the CD rom bugger it up?

BTW, this has been a really fun thing to play with. Thanks for helping me out.! =)

Link to New Variation: http://home.comcast.net/~alphaeight/ImgBrowse.zip
Ozone

Nice work there, very nice I'd suggest setting the path control style to "overflow: hidden" (and possibly "text-overflow:ellipsis"), because when in a deeply nested folder it screws up the layout.

Also I noticed you got rid of the path links idea. Not a problem (although I like it), but why not make it a text box so the user can directly enter the path? Using fso.FolderExists() you can test if it's a valid path and fso.GetFolder() will retrieve it.

I've been playing around with a little idea of mine, having a stub executable (say thing.exe) which just calls "mshta.exe res://path\to\thing.exe/index.hta". Using this you can embed all the HTML, graphics and so forth inside the resources of the exe, and have it run as a HTA. This could be perfect for your CD thing (mainly because you can specify the icon, like any exe), if you're interested.

I assume you're working on some sort of HTA project here... I'd be interested to see it finished

Well, that took a large sledgehammer to acomplish! But it is done... Same link as before... Restored your clickable path, which was a good idea.. I only axed it to get a drve letter up there. Had to recode a bit to make those work together. Then came the text-feild area. *UGH* I was picky about how I wanted it to react, and was dead set for making enter fire off the typed in path! Unfortunately, enter wont work in a form field, unless it is contained in a form, with actions and methods and such. No problem.. put those in. Worked FINE in HTA and standalone, but the popup INSISTED that a submitted form was going to result in a new window NO MATTER WHAT! (Lil' turd!) So with a HUGE sledgehammer I bashed in some keyboard trapping to try to force the issue. 98% effective I think! Now typing keys when the text-entry isnt visible brings it up, and puts you at the end of the current path. Of course, you can delete the whole thing and manualy enter whatever you like. If it works, it goes there.. if not, it don't! Only problem I have encountered is that it is still best not to hit enter when the text area isn't up, or it'll try to submit (read:spawn a turdly little window). Pretty awsome result I think. I suppose I could slag in some more keyboard commands since the key-trapping is already in, but this thing is getting fat enough already!

Regarding your HTA / EXE packaging idea, that sounds freaking awesome. Catch is, only half of my HTA is actual HTA, the rest is non APPLICATION html framed inside. Plus most of the BIG graphics are accessed by the non HTA portion.

I think what would work best would be a simple widget with a presentable (and setable) icon that:
could be set to autorun from the CD, and
that would activate the HTA, then unload itself.

Right now, I've got a noce opener widget that WILL launch the HTA from autorun, but it isn't "stand alone". When I presented my beautifully crafted autorun CD to my last prospective client, he futzed around for a couple of minutes (while my heart sank into my shoes), then browsed the CD drive, and started clicking on the items w/ pretty icons (Which the HTA had none). He explained later that he had autorun disabled on the drive. *DOH* I had to guide him throught the nasty guts of the root directory to the right file before I could begin. I'm sure the clutter wasn't very impressive, nor the lack of a "NEON SIGN" saying "CLICK HERE TO START"... sigh.... poor end-users sometimes. But I need to fix this up so that won't happen next time.

*GASP*

Long-winded today eh? LOL. Sure you still want to see something like that!? hehehe

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