fxm

Background: I had a working application on multiple XP/Vista systems which I was trying to run on Win_7. Using references pfovided by Ascend4nt and code provided by Ascend4nt, KaFu, and klaus.s (see ) [thanks again to all!] I was able to get just enough of the application to work with DirectUIHWND - albeit somewhat inelegantly - while learning something about objects and a little about the shell. Now, however, the scope of the task has changed and I am sorely feeling the [apparent] lack of some SysListView32 methods that I had taken for granted would be available somewhere in the DirectUIHWND environment - but have not been able to find. The clearest example is the "FindItemWithText()" method - implemented in ControlListView() as the "FindItem" 'command'. Issues: 1. I was prepared to emulate that method on DirectUIHWND using only the primitive methods in the sample code, but before slogging through such a brute force attack [iterating a FolderItems collection, applying ParseName(), etc.] I was hoping that someone might suggest a less tedious/crude solution. 2. Since writing the previous paragraph and - luckily - before I actually started trying to grind out the code, I was cautiously excited to find the IFolderViewOptions interface, which has Get/Set methods to manpulate the FOLDERVIEWOPTIONS enumeration typedef enum FOLDERVIEWOPTIONS { FVO_DEFAULT = 0x00000000, FVO_VISTALAYOUT = 0x00000001, FVO_CUSTOMPOSITION = 0x00000002, FVO_CUSTOMORDERING = 0x00000004, FVO_SUPPORTHYPERLINKS = 0x00000008, FVO_NOANIMATIONS = 0x00000010, FVO_NOSCROLLTIPS = 0x00000020 } FOLDERVIEWOPTIONS;The item in that list of interest to me in solving my problem is FVO_VISTALAYOUT (Use the Windows Vista list view). If that works as I hope, I will be back in the land of SysListView32 - and as the old joke goes, I have already solved that case. Questions: 1. Can anyone tell me whether there is an obvious [to everyone but me] simpler approach - possibly using a different object reference or even an existing DirectUIHWND method that I have missed? 2a. Assuming that I have a shell object pointing to a window displaying the desired folder, would this $rtn = $oShellToFilelist.IfolderViewOptions.SetFolderViewOptions(1,1)do what I want? [i may be missing a qualification level and I'm not at all sure of the format of the parameters (must I use an array or struct?)]. 2b. Can that be done on the fly? Or do I have to do it when the window is created? If on the fly, do I have to refresh the window for it to take effect? [My apologies for asking these three questions - I don't have a Win_7 system on which to test.] 3. [related but strictly-speaking not on topic for this forum] I gather that there is some sort of "compatibility" setting on Win_7. Is it possible that marking my .exe on the Win_7 system in some way as requiring Vista-compatibility would make this problem go away with no programming on my part?

Using your example and references [thanks again!] I was able to port the basic functions from SysListView32 to DirectUIHWND - while learning a lot about objects and something about the shell. Now, however, the scope of the task I am automating has changed and I am feeling the [apparent] lack of some SysListView32 methods that I had taken for granted would be available somewhere in the DirectUIHWND environment. The clearest example of these is the "FindItemWithText()" method - implemented in ControlListView() as the "FindItem" 'command'. Before I try to implement such a function by brute force [iterating the FolderItems collection and applying ParseName()] can you confirm for me that there is no more straightforward way? [i had enough difficulty navigating the MSDN documentation for the objects I need to access for each method I want to use that I wouldn't be at all surprised to learn that I have missed something very simple.]

Awesome!Unfortunately the problem application is on a client's PC which I can't access at the moment. If it weren't for that, I would be testing up a storm right now. I'll report back as soon as I can. Thanks.

What it returns seems obvious. Unless I'm missing something, what it does is read-only. For example, it doesn't emulate ControlListView($sWDF, "FolderView", "SysListView321", "SelectClear")or ControlListView($sWDF, "FolderView", "SysListView321", "Select", $iIdx) Now that I know what to search for, I am finding discussions about the transition to DirectUIHWND. Perhaps I can solve my problems with ControlSend() or equivalent.

This $sWDF = StringMid(@WorkingDir, 1 + StringInStr(@WorkingDir, "\", 0, -1)) $iRtn = ShellExecute(@WorkingDir) works on all platforms. A directory list for the folder ["GAMEFILE" in this case] is opened in a new window. This WinWait($sWDF, "FolderView") If Not WinActive($sWDF, "FolderView") Then WinActivate($sWDF, "FolderView") WinWaitActive($sWDF, "FolderView") fails in Win7/64 because the string "FolderView" is not found. Changing that to "ShellView" [the string which is actually present] WinWait($sWDF, "ShellView") If Not WinActive($sWDF, "ShellView") Then WinActivate($sWDF, "ShellView") WinWaitActive($sWDF, "ShellView") works [sets the focus as expected]. Now we come to $sNew = "110930A.HTM" $iIdx = ControlListView($sWDF, "ShellView", "SysListView321", "FindItem", $sNew) the minimal failing case. The essential problem at this level is that there is no "SysListView" control of any kind anywhere in the window. The part of the window containing the filelist has [as reported by AutoitWindowInfor] a ClassnameNN of DirectUIHWND3 but taking a wild guess and making the rote substitution $iIdx = ControlListView($sWDF, "ShellView", "DirectUIHWND3", "FindItem", $sNew) doesn't return the expected value [not much of a surpise].

I have an existing script which works properly in XP and Vista. In Win7/64 [i chose the "64" option at Autoit install time] a couple of functions I use appear not to work. The most basic problem appears to be that folder displays are very different in Win7/64. For starters, according to AutoitWindowInfo a SysListView control no longer exists in the window. I half expected that SysListView32 would be gone but I can't even see what - if anything - has replaced it, let alone how to interact with the replacement. [Expecting to see SysListView64 was evidently too naive by half.] Can someone give me a pointer to a relevant thread? I haven't had much luck searching this forum for "windows7" and similar.

I have existing scripts that open a folder using the command ShellExecute(@WorkingDir) In all versions of Windows up to Vista the result was a window with a text parm of "FolderView". In Win7/64, that parm turns out to be "ShellView" for some reason. It isn't obvious - to me anyway - whether there are functional differences between the two. And even if there are, I wouldn't be surprised if they are effectively identical for my purposes. My question is: can that command [or equivalent] open "FolderView" in Win7/64? Or must I modify my code to allow for both possibilities?

It isn't immediately clear [to me, anyway] how to convert the address of a webDAV folder [e.g., http://home.comcast.net/~username] or an ftp [possibly virtual] folder [e.g., ftp://username@upload.comcast.net] to UNC form. I appreciate any pointers or help but I realize that this may be getting somewhat off-topic for this forum.

I will look into that. I hadn't considered that solution because my first attempts on Win7 with "net use ^ path..." [which is, I assume, the underlying function] failed when the target was a webDAV folder or the path contained [at least some] special characters.

Mostly because I started by automating a manual process Plus, I don't look forward to giving up pattern matching either in ControlListView [which makes it easy to select varying numbers of files with dynamically chosen names] or in ControlTreeView [which makes it easy to validate/navigate target-installation-dependent folder structures]. Besides, I still need some way to locate the target folder name on Win7 systems. That being said, FileCopy() is Plan B.

I am dynamically selecting files to copy. These steps ControlListView() ; open the source folder Send() ; activate "Copy to folder..." selection work in WinME through Win7. The next step ControlTreeView() ; select the target folder. fails in Win7 only. The problem is that the desired target folder [a Network Place] does not appear in the TreeView in Win7. In the other OSes it does appear in the structure, albeit at an OS-dependent location. Is there a way in Win7 to have a Network Place appear in the "Copy items" SysTreeView32? Or do I need to code a work-around in Autoit?

/

Windows XP/SP3. I'm late to this old thread but I wanted to add a comment about the error message from Aut2Exe "unable to create compiled archive" (and other errors/failures discussed above). In my case a completely effective workaround was to disable the [ ] Use UPX option. So long as that option is enabled, it appears than an AV rule [in Microsoft Security Essentials I think] blocks the .exe file from being written. I also experienced intermittent compile failures [using SciTE and GUI wrapper directives] which were completely eliminated by making sure that when the folder containing the source happens to be open in Explorer at the time of compilation, the file being compiled does not have the focus.