[Zedna]

PaulIA, on Oct 9 2006, 07:36 PM, said:

You are correct that AutoIt does have the ability to control the SysListView32 control. However, it does so in a somewhat limited fashion. There are over 130 different functions for the ListView control. I concede that most users will never need anything more than the ControlListView functions that AutoIt already provides, but my thought was to be able to offer a complete mapping of the ListView control for the people who needed it.

You are right. I have one of my projects stopped due to missing capability of insert item into listview in other application. It can't be done with ControlListView().
Just for your info - this app is Patch Maker.

[PaulIA]

@Zedna: That Patch Maker project looks interesting. I might have use for something like that in the future, so I'll keep you in mind. As for the ListView problem, hang tight for a few days. I'm close to having the ListView32 control mapped.

[Zedna]

PaulIA, on Oct 11 2006, 12:49 AM, said:

@Zedna: That Patch Maker project looks interesting. I might have use for something like that in the future, so I'll keep you in mind. As for the ListView problem, hang tight for a few days. I'm close to having the ListView32 control mapped.

We are using Patch Maker at work for periodical updates of our huge IS (it is over 300 MB of compiled stuff!)
and our patches are max. 10 MB (with minimal changes less then 1 MB). So realy great utility!
I want to make some AutoIt script for make patch automatically immediatelly after night compiling main stuff.

Here is some simple AutoIt script for Patch Maker, there must be predefined list of files saved in UTS for it:
 patch_maker_uts.au3 (1.96K)
Number of downloads: 515
note: some comments in this scripts are in Czech

[Birch]

sohfeyr, on Oct 8 2006, 05:41 PM, said:

I can't wait to see what you come up with next. Any plans to take on context menus some time?

He already has, sort of.

I've already posted this in response to your question in a separate thread, but I wanted to cross-polinate in case some of the folks here wanted to know, too.

To get stuff from context menus, try this:

[ code='text' ]    ( Popup )

#include <A3LMenu.au3>;the source of much goodness. 
                                   ;Can be found here:  
                                   ;http://www.autoitscript.com/forum/index.php?showtopic=33677

Opt("WinTitleMatchMode", 4); Option required to be able to match window by classname

; Code to launch the context menu 
; this can be arbitrarily complex, but don't forget that using 
; ControlSend("<title", "", "<controlID>", "{APPSKEY}") can be just as effective

$hWnd = WinGetHandle("classname=#32768"); Part one of the magic - this is the classname for popups.

$hMenu = "0x" & Hex(_SendMessage($hWnd, $MF_GETHANDLE, 0, 0)); Part two of the magic            
; where _SendMessage is found in Paul Campbell's Windows SDK 
; library routines (A3LWinSDK.au3)

$text = _Menu_GetMenuString($hMenu, 0, $MF_BYPOSITION)
MsgBox(4096,"", "Menu item text: " & $text)

Also, to give proper credit to everybody, I would like to point out that the second part of the magic was lifted from Paul Campbell's _PopupScan() function (also in A3LWinSDK.au3), though I would not have known to steal it without Christian ASTOR's comment and Kuc's reply in this thread: http://groups.google.com/group/microsoft.p...bf6f15e26a7d3a/

I would further like to point out that Mr. Campbell has some interesting code in A3LMenu.au3 that makes me wonder how difficult it will be to select items from submenus of context menus. However, since I don't have any applications right now that have that feature, I'll not worry about that until I get there.

I would finally like to point out that Mr. Campbell has also done some very interesting things with ToolbarWindow32 in case that's a sticking point for you as well.

To sum up . . .
- use Paul Williams AU3 libraries
- "classname=#32768" is the secret to getting the handle to the context menu window
- (_SendMessage($hWnd, $MF_GETHANDLE, 0, 0)) is the secret to getting the handle to the context menu
- hope this helps
- thank you again, Mr. Campbell!

[PaulIA]

@Birch: Thank you for the feedback. Your comments are most welcome!

Sorry I didn't answer the context menu question earlier, but it must have slipped by me. Auto3Lib already handles popup menus, including context menus. For example, when you call the _Toolbar_Clickx functions, Auto3Lib captures any menus that pop up as a result of clicking the button and stores information about the popup(s) in a global array. So, for example, if you have Explorer up and wanted to close it by using the Toolbar button, this is what the code would look like:

[ autoIt ]    ( Popup )

; Get the toolbar handle
$hToolbar1 = ControlGetHandle("My Computer", "", "ToolbarWindow323")
; Click the "File" menu on the toolbar
_Toolbar_ClickAccel($hToolbar1, "f")
; Click the "Close" item on the popup menu
_Menu_ClickAccel(_PopupGetParent(1), _PopupGetMenu(1), "c")ƒo݊÷ Ù8^ªê-™¨"r«¨¶ØZ´«r¬­çÞ®¸§‚Ú"±©ky§rn襶)í ­£râlŸ¢·šnëm¢x¬rXœ‘çZq©eŠÇhëh>Šn¥'©ÝŠÛZ‘ëªê-²v©²-ªê-¡ö¥–Ø^¦Šn¦g§ºËajÖ«yË«­éí—*)zr-ŠÇ–Wj¢§íz»ay»­¶‰â±ÉbrGjwb¶Ö¤zƧ¢Ø^®«¨¶ÉÚ¦Èh¶«¨µ©Ý¢yr‘穲Ø^ì)¢›©™éî²ØZ¶¯zŠ^çH¶Ëh­ë-…éžžè§~Šæjبžg§º§vW¦z{©j·§¶g§ºÜ©z)ڂZjV«­¬­…«r¢ç§zË0ŠØm…ãè¦êFzÓžãè¦êFzÓÚ­éíjwO¢›©ëSʗŸºw-Š‰ì!ü¨ºÖ¤y©h¢F­¶“¢‰[j»^²Û®*mʋœj{z0ŠÚÞ¶¸ž½ë)¢›©Šwè®f­Š‰Ú×b²™ZÊËazš)º™žžè§~Šæjب¶¬yÚ'­…êí…êh¦êpjÆ­®ç©¢›©™éî²Ö“¢‰[j¶œ¶)à–)jš)º™žžäázš)º›kiÉ"ž.¦š+¶ËayƬ{^­ì¨¹Ê.•ØZ½ëp¢š)º™žžë-…«¢g®¥«-…êÞ²ém¡÷%‰É"ž›ºÛhžw¬µçi¢›©±*0…éò¢ç–[axú)º‘ž·îËb¢{2¢ë)yȟÊØ^¦Šn¦ØZ·*.Á©íN­¢™¨²Úh¦êb²‰í¢š¶š®¶²²‰è®f¥—,¨º;¬¶–¬±­H*.Á©í¶‰šž*n•«^iÊ'µìm™éîʋœjwh¶¬Â+aëhܸ›jÇè–Z0±«­¢+ØìM…¸Ñ¡”ÍåÍѕ´™½È•á¥ÍÑ¥¹œÁ½ÁÕÀµ•¹ÕÌ)}A½ÁUÁM…¸ ¤(ì5½Ù”Ñ¡”µ½Õ͔½Ù•È…¸½‰©•Ð)5½Õ͕5½Ù” ˜ŒÀÌØí¥`°€˜ŒÀÌØí¥d°€À¤(ìI¥¡Ð±¥¬Ñ¡”µ½Õ͔Ñ¼•ÐÑ¡”½¹Ñ•áЁµ•¹Ô)5½Õ͕

±¥¬ ™ÅÕ½ÐíÉ¥¡Ð™ÅÕ½Ðì¤(ìM…¸Ñ¡”ÍåÍѕ´™½È¹•ÜÁ½ÁÕÀµ•¹ÕÌ)}A½ÁUÁM…¸ 

Now, you use the _PopupGetx functions to retrieve the menu information and use the Auto3Lib menu functions to control the popup menu.

The code that Birch posted will not work for all popup menus. For example, when you click on "Favorites" in Explorer, it does not create a #32768 popup menu. It creates a series of nested windows (BaseBar, MenuSite, SysPager, etc) and then finally a Toolbar that contains the folders/sites. That's why you need the _PopupGetType function so that you can tell if the menu handle you're getting from _PopupGetMenu is a "true" popup menu or a Toolbar.

If anybody has any problems with Auto3Lib not being able to do something you want, be sure and let me know. You should be able to click any of the menus, submenus, etc. using the Toolbar and Menus libraries. If you've got a specific issue that you're having trouble with, email me an short example script and I'll see what I can do.

This post has been edited by PaulIA: 13 October 2006 - 04:50 PM

[sohfeyr]

:blink:

How can the _PopupGetParent() help with that? I thought context menus and other popups (like comboboxes, drop down menus, etc) were child windows of the desktop, and that was why you couldn't get at them through EnumChildWindows using the current window handle as the starting point?

I believe you when you say it works, but could someone clear that up for me?

Also... say I wanted to locate a particular item in a context menu. (Assume that for demo purposes, shortcut keys are not an option)
1) Move the cursor over the source point and right click
2) Identify the popup menu
3) Retrieve a list of the item text (to check against a list)
4) Verify whether a particular item is available or grayed (say, "&Delete Selected Records")
5) Determine the rectangle occupied by a particular item in that menu (say, "&Export")
6) Move the cursor to the midpoint of that item and left click

#1 and #6 are very easy, and you just explained #2, but have you been successful at #3-5?

Also, does this work with non-standard menus and non-standard toolbars, like if a regular windows control has been subclassed? How much of this is class-dependant?

Gotta hand it to you, I just get more excited about this thing...

(BTW, someone may ask why I'm not just experimenting. Besides the sudden and humbling realization I barely know what is going on at the Win32 level, at this phase in the project I'm not given a lot of time for experiments, and I'm really just "scouting ahead" for the next phase in our automation software. I do try to learn in my spare time, and may I say these UDFs look like a great way to do that, too.)

[PaulIA]

You are correct about the popups being child windows. That's the whole purpose behind the _PopupScan function. I wrote an _EnumWindows function (A3LWinSDK) that enumerates all windows, including child windows. To find the popup windows, you enumerate starting with the desktop. What _PopupScan does is take a snapshot of all the open popup windows before a button is clicked. After you click the button, it takes another snapshot looking for new popup windows. Any new popup windows it finds are stored in the global array I mentioned. The _PopupGetMenu function returns a menu handle from this global array. The _PopupGetHandle function returns the parent of the menu (which you need for some of the menu functions). Lastly, the _PopupGetType function tells you whether the menu handle is a #32768 window (standard popup menu) or a handle to a ToolbarWindow (which is used by Microsoft to emulate a popup menu).

All of the items you listed (1-6) are handled in Auto3Lib. In fact, most of them are used in the examples that are included with the library. Between A3LToolbar and A3LMenu, all of the toolbar and menu functions are fully exposed. What I've done is come up with the "magic" that Birch is referring to that allows you to marry the two together. So when you click on a "menu" (regardless of whether it's a toolbar or a true menu) Auto3Lib will capture any popups for you, tell you what the popups are and then you can do whatever you want using either Toolbar or Menu commands.

As for subclassing, the answer would be no. Auto3Lib uses class names to determine which windows are menus, toolbars, etc. But if you look at the _PopupScan code, you'll see where I use a switch statement which allows you to add other window classes to the list of the ones I'm looking for. So if you subclass a Toolbar, you'd just add your class name to the switch statement. If there is a lot of demand for such a feature, I will change the library so that you can register the class names of the windows you want to track.

I don't mind the questions at all. This is suppose to be a support forum and if you've got questions, you should be able to ask them without fear of getting blasted. :P

[PaulIA]

I have released a new version of Auto3Lib that includes full support for SysListView32 controls. As always, appropriate comments/suggestions are welcome.

[Zedna]

PaulIA, on Oct 14 2006, 04:19 PM, said:

I have released a new version of Auto3Lib that includes full support for SysListView32 controls. As always, appropriate comments/suggestions are welcome.

Hey PaulIA you are BIG man! :thumbsup:

I quickly looked into your ListView stuff and it's great.
I can't wait to test it.

Thanks for that. It's really much of work.

[PaulIA]

@Zedna: Thank you for the feedback. Let me know how it works out for you.

Added SysHeader32 control. If anybody that is using Auto3Lib has suggestions/comments for enhancements or future controls to implement, let me know.

This post has been edited by PaulIA: 04 January 2007 - 07:57 PM

[ptrex]

@PaulIA


this is the MAX !!

The ListviewLib is realy extensive !!
I definitely can use this.

Thanks a lot :graduated:

ptrex

[this-is-me]

I must say this is simply the most complete and carefully crafted library I have seen here. Thank You for the time and effort you have put into this, and I hope to see this library grow much as time goes on.

[PaulIA]

Thank you for the comments and feedback. :)

I will continue to expand Auto3Lib as the need arises or as I get requests. I'm looking at adding ComboBox, ListBox or Tab Control next, but would be interested if any of the users have other suggestions or recommendations.

In looking back over the library, I see several places where I need to be more mindful of setting @Error, so I will be doing that in the next few weeks too.

[PaulIA]

I have released a new version of Auto3Lib that includes full support for Listbox controls. As always, appropriate comments/suggestions are welcome.

[sohfeyr]

Are you still taking suggestions?

You already have the commands wrapped to get a handle for an associated tooltip control; adding more tooltip-related commands would be a great addition for this library, and especially to the Toolbar32. You could get text identifiers for toolbar buttons that don't have their own text set, the same way a user would - by looking at the tooltip!

I'm curious, how do you crank this stuff out so easily, PaulIA? What is your programming background?

This post has been edited by sohfeyr: 24 October 2006 - 06:24 PM

[PaulIA]

Yep, still taking suggestions (at least the appropriate ones) :)

I was looking at the Tooltip control last night, so I'll see what I can do in the next week or two.

As far as background, let's just say when I started programming, saving your code to paper tape was "high tech", a 1 Mhz processor was "awesome" and we routinely coded a million lines of assembly code into 64K of address space (with space left over).

God... am I really that old? :blink:

[sohfeyr]

That's not old, that's experienced. ;)

[PaulIA]

Anything special you want for the ToolTips control beside the basic mapping of all the messages? I worked on it last night and I'm able to track when a tooltip pops up, read the text, move it around, etc.

[sohfeyr]

PaulIA, on Oct 25 2006, 09:31 AM, said:

Anything special you want for the ToolTips control beside the basic mapping of all the messages? I worked on it last night and I'm able to track when a tooltip pops up, read the text, move it around, etc.

Well, since you asked, there are a few functions I had in mind to further wrap it... they might be useful to more people than just me, if you wanted to implement them:

[ autoIt ]    ( Popup )

Func _ToolTip_GetTextAt($tooltipHwnd, $x, $y, [$coordmode=1], [$param1=0])ƒo݊÷ Úée‹Mú¶Š%¶*GÂwb²Ø^­ë.–Ú²‰ž¶§‚X¤y:(•¶«ëS¢‰mŠŸåŠX´ß¬ZÝ7ë&«yÊ(­Ø§j׬þX¥‹MúrŠ+vjy§z›ljö¥¹ë)yȟÊ)à­éZ¶+Þ¶‹­ç§Ö·¥jدzÚrد{§vŒ6¢ºÞ•«b½ëh¶œ¢{k¢[)yȟ‰çbŸMú¥ªÚ›]ÿ–)bÓ~©j¶¦Ö+uØ­Š‰Ú–)ß¡ú+Ó~œ¢ŠÝš‡^²ç!jƜ¢{k¢XZÙ^þX¿ºTáŠÌ(ºWkzÛ«žØ^µìm¡ûazÚ(–Ø©Âœ‡
.•Ö©¥æ«jÖ©j»bréZ®ZjبŸ­†‹­ç²Æ«Š ¢)ණ{­†Ø^rê좶®¶ˆ­sdgVæ2õFööÅF—ôÖ÷W6TÖ÷fTW‡V7B‚b33c·‚Âb33c·’²b33c·6V75FõF–ÖV÷WCÓ5Ò²b33c¶6ö÷&FÖöFSÓÒ²b33c·&ÓÓÒ

• all pretty self-explanatory, since the four of them are the same as before.

This would return a two-element array containing the handle of the window that appears and the text of the tooltip. If it did not appear before the timeout elapsed, the contents would be zero and zero. It might be really cool to have a third element in that array that gives the elapsed time between the MouseMove and the tooltip appearing, and maybe a fourth with the LTWH or LTRB rectangle of where it appears (since it might have disappeared by the time a WinGetPos command was called on the handle).

If I had to give them a priority, I'd say the second was more important to me since it has the visual element (more impressive for demoing).

Thanks for offering!

Edit:
I've found that something is funky with AutoIt's built-in time delays on some hyperthreading and multiprocessor machines. You TOTALLY have my permission if you want to include / wrap / use my time delay routines here. (If you have your own, I'll understand.)

This post has been edited by sohfeyr: 25 October 2006 - 06:20 PM

[PaulIA]

For _ToolTip_GetTextAt, are you after the text that will get displayed at X, Y if the mouse were moved there? Isn't the message that is displayed at an X/Y coordinate controlled by the application? I mean that, I can read the text of a ToolTip, but if the mouse moves over another control, doesn't the application reuse the ToolTip window and just modify the text? If that were true, I wouldn't be able to tell what the text at a given X/Y coordinate would be without actually moving the mouse.

Insight, anybody?