| View previous topic :: View next topic |
| Author |
Message |
suxi Newbie
Joined: 16 Jan 2005 Posts: 23
|
Posted: Fri Feb 04, 2005 1:46 pm Post subject: No Windows Identifier under XP? |
|
|
Hi Everyone
I use the following to get the Windows Identifier of the Richedit field of an external program. I need this Identifier in order to read the text from this field with the @wintext(%%table_id) function.
PARSE "%t;%l",@winpos(##32770,TL)
%t = @fadd(506,%t)
%l = @fadd(383,%l)
%%table_id = @winatpoint(%l,%t)
The WinSpy utility correctly lists the Identifier and I receive the correct value under Windows 2000. Under Windows XP the Winatpoint function only returns the Identifier of the Parent Window.
Do you have an idea why this happens and how I can correctly receive the Identifier of this field? I can’t read out the content with the Winclass name (#richedit), it only works with the Windows Identifier, which changes every time the program is run.
Thank you very, very much for your help, as this problem brings my little project to an abrupt hold.
suxi |
|
| Back to top |
|
 |
jules Professional Member


Joined: 14 Sep 2001 Posts: 1043 Location: Cumbria, UK
|
Posted: Fri Feb 04, 2005 5:41 pm Post subject: |
|
|
You need to figure out how to navigate to that element starting from the main window, using @window(...,next) and @window(...,child). A dialog is kind of a tree structure, with the dialog itself at the root. The Windows Spy should give you a clue to the structure by the indentation. _________________ The Tech Pro
www.tech-pro.net |
|
| Back to top |
|
 |
suxi Newbie
Joined: 16 Jan 2005 Posts: 23
|
Posted: Fri Feb 04, 2005 7:55 pm Post subject: |
|
|
Hi Jules
Thank you for answering so quickly! The Winspy shows me 61 components. The particular richedit field is the third from the bottom.
Is there somewhere more documentation about the @window command? I don't really understand the parameters yet.
How would I start to work my way through all of these 62 controls and how would I make this "tree structure" visible for me?
Thank you very much for your help and have a nice weekend
suxi |
|
| Back to top |
|
 |
Serge Professional Member


Joined: 04 Mar 2002 Posts: 1480 Location: Australia
|
Posted: Sat Feb 05, 2005 1:06 am Post subject: |
|
|
hi suxi,
jules mentioned in his post how to do it
| Code: | | You need to figure out how to navigate to that element starting from the main window, using @window(...,next) and @window(...,child). A dialog is kind of a tree structure, with the dialog itself at the root. |
have a look in the the vds help file for @WINDOW() and all the parameters you can use. There is a LAST and a PREV which should help.
I did manage to get the whole thing working for me once many years ago so i can't help you more than this at this stage as my memory isn't that good
serge _________________
|
|
| Back to top |
|
 |
suxi Newbie
Joined: 16 Jan 2005 Posts: 23
|
Posted: Sat Feb 05, 2005 11:26 am Post subject: |
|
|
Hi Serge
Well, even reading it twice doesn't realy make me understand it
By simply using @window(%%winclass,next) I get over hundred of identifiers, but not the ones listed in the spy application.
I have then tried the following script, playing around with my counter %c:
%b = @window(##32770,next)
%c = 11
repeat
%b = @window(%b,next)
list add, list, %b
%c = @fsub(%c,1)
until @zero(%c)
%b = @window(%b,child)
list add, list, %b
:loop
%b = @window(%b,next)
list add, list, %b
if @not(@null(%b))
goto loop
end
It looks like my identifier is a child of one of the identifiers I get by simply using the "next" parameter. Sometimes I even manage to find it by trial and error. Unfortunately the amount of parent identifiers seem to change, so I can't use a fixed counter to work my way through this terrible tree structure.
I really would appreciate more information about how this tree structure works and why the winspy utility shows my identifier straight away at the same position, but I can't find it by using plain @window( ,next) commands.
Again, thank you all so much for any help and have a continuing nice weekend
suxi |
|
| Back to top |
|
 |
Serge Professional Member


Joined: 04 Mar 2002 Posts: 1480 Location: Australia
|
Posted: Sat Feb 05, 2005 1:06 pm Post subject: |
|
|
| Quote: | | Well, even reading it twice doesn't realy make me understand it |
sorry suxi, i thought you might have missed it
i'm not sure what to recommend at this stage, perhaps someone more knowledgeable can help
one thought, if the identifier you seek has the same name all the time, then just go through all the trees and their branches until you find the identifier with the name you are after
i had thought of doing something like that for one of my programs and just gave up as it was too complicated for my little brain
one of the problems i think, which explains your comment, is that windows assigns identifiers to each window open and each time you open a new window, then the identifiers change too
however, i am surprised to see that even the tree structure changes
may be jules can help you after the weekend unless someone else knows how to help you
serge _________________
|
|
| Back to top |
|
 |
suxi Newbie
Joined: 16 Jan 2005 Posts: 23
|
Posted: Sat Feb 05, 2005 4:17 pm Post subject: |
|
|
I am getting closer The problem is that there are more programs with a class name of ##32770. The @windows command simply scrolls through all of them and I currently can't think of a clever way to figure out which one is the one I am interested in. Within my program the tree structure seems to remain the same. Maybe I can count the amount of child ids and hope that none of the other ##32770 programs have the same amount? Well, that looks more like an ugly work around.
Later
suxi |
|
| Back to top |
|
 |
Serge Professional Member


Joined: 04 Mar 2002 Posts: 1480 Location: Australia
|
Posted: Sat Feb 05, 2005 11:18 pm Post subject: |
|
|
hi suxi,
interesting that your window class is #number as mine under windows 98se are all names such as #TMainWin or #TPanel
in any case, your #32770 should not change as %numbers are the ones assigned by windows and these do change each time the program is run
you can count the number of branches and children as that should not change
serge _________________
|
|
| Back to top |
|
 |
Mac Professional Member

Joined: 08 Jul 2000 Posts: 1585 Location: Oklahoma USA
|
Posted: Sat Feb 05, 2005 11:35 pm Post subject: |
|
|
Hey suxi,
I think #32770 is a common Windows messagebox, usually
displaying an error message or a yes/no/cancel window.
The spytool I wrote in VDS might give ya some insight
into your project - the source code is here:
http://www.vdsworld.com/forum/viewtopic.php?t=450
There are two versions posted there - not sure how they
work in XP though.
Cheers, Mac  _________________ VDSug.dll does file IO, check/disable menu items,
non-VDS dlls, draw functions and more...
Free download (30k dll size) at:
http://www.vdsworld.com/download.php?id=361
 |
|
| Back to top |
|
 |
suxi Newbie
Joined: 16 Jan 2005 Posts: 23
|
Posted: Sun Feb 06, 2005 12:50 am Post subject: |
|
|
Thank you Mac, your spy tool is great. Much better then the vds spy app.
Unfortunately ##32770 really is the class name of that window. I have now counted the identifiers under the child identifier in my app and wrote a subroutine going through all active ##32770 programs, counting the children. Like this I magically always find the right identifier. I just hope that no other ##32770 will ever have the same amount, because that would cause a desaster
Well, this was a tough one. It took me many hours to figure that one out. But as always, the reward is great, I am over the moon and go to bed now.
Thank you very, very much everyone for helping. If I wouldn't have found vdsworld, I wouldn't have registered VDS.
Take care everyone!
suxi
PS I still wonder why XP differs so much in this aspect from 2000 |
|
| Back to top |
|
 |
PGWARE Web Host

Joined: 29 Dec 2001 Posts: 1566
|
Posted: Sun Feb 06, 2005 5:22 am Post subject: |
|
|
| XP may be different because of the new common controls (xp themes). The controls may use different methods for creations of window controls thus the level of child id's is probably different. You can confirm if this is true by compiling an app in XP with a theme manifest file and then compiel the same exe without a theme manifest file (this will use the old common controls). See if the level of child id's/windows changes. |
|
| Back to top |
|
 |
|