Retrieve the position (X,Y) of an HTML element

Started by hdsouza, December 10, 2014, 05:43:42 PM

Previous topic - Next topic

hdsouza

What is the correct syntax to Retrieve the position (X,Y) of an HTML element
I have tried:
Code (winbatch) Select
Obj_Right = div.style.right

and
   
Code (winbatch) Select
Obj_Right = div.getBoundingClientRect.right

Both return no value

Also I am able to do a div.focus(@true) to move it into focus

mhall

Have you tried getComputedStyle?

http://ie.microsoft.com/testdrive/HTML5/getComputedStyle/Default.html

Quote
getComputedStyle is a method within the DOM Style specification which provides access to the final computed style of any element within a document. This is helpful because frequently styles may apply to an element from multiple sources. Using the computed style lets you know all of the final styles and final absolute values which applied to the element.

hdsouza

Quote from: mhall on December 12, 2014, 01:09:12 AM
Have you tried getComputedStyle?

http://ie.microsoft.com/testdrive/HTML5/getComputedStyle/Default.html

Quote
getComputedStyle is a method within the DOM Style specification which provides access to the final computed style of any element within a document. This is helpful because frequently styles may apply to an element from multiple sources. Using the computed style lets you know all of the final styles and final absolute values which applied to the element.


Micheal, I am not able to get getComputedStyle to work in winbatch. Also there does not appear to be any code on the winbatch formus on this methord.
Any help would be great

mhall

Well then I may have put my foot it it!  :-[

Unfortunately, I don't have a lot of experience in accessing HTML values/attributes via WinBatch, but I work in Javascript a lot and that method popped to mind.

But ... I did have a fiddle and was all set to give up, when I got this to work (well, at least start returning CSS values):


url               = ''    ;// YOUR URL
tag_id            = ''    ;// YOUR TAG ID


;// ADAPTED FROM TECH DB ARTICLE
Browser           = ObjectCreate("InternetExplorer.Application")
browser.visible   = @TRUE
browser.navigate( URL )
while browser.readystate <> 4
       timedelay(0.5)
endwhile
BrowserDoc  = Browser.Document
BrowserBody = BrowserDoc.Body
BrowserPage = BrowserBody.CreateTextRange
BrowserText = BrowserPage.Text


;// GET REFERENCE TO THE DOM ELEMENT
dom_element = BrowserDoc.getElementById( tag_id )

;// GET COMPUTED STYLE - IS A METHOD OF BROWSER.PARENTWINDOW
;// RETURNS A STYLE OBJECT, ACCESS USING NORMAL STYLE NAMES
computed_style_object = BrowserDoc.parentWindow.getComputedStyle( dom_element );

message( 'left', computed_style_object.left );

exit




Hope that works out!

Regards,
Micheal

hdsouza

Micheal, Thanks for the code. I think we are close. I am getting an output which says AUTO. I was looking to get the actual X , Y, XX, YY coordinates though.
The BrowserText is also blank. Not sure if something was expected there

Code (winbatch) Select

URL = "http://www.winbatch.com/techsupt.html"
tag_id = "headerimage"

Browser           = ObjectCreate("InternetExplorer.Application")
browser.visible   = @TRUE
browser.navigate( URL )
while browser.readystate <> 4
       timedelay(0.5)
endwhile

BrowserDoc  = browser.Document
BrowserBody = BrowserDoc.Body
BrowserPage = BrowserBody.CreateTextRange
BrowserText = BrowserPage.Text

dom_element = BrowserDoc.getElementById( tag_id )
computed_style_object = BrowserDoc.parentWindow.getComputedStyle( dom_element )
message( 'left', computed_style_object.left )

mhall

In cases like that, I don't think you'll be able to retrieve an actual value for it - that's not a positioned element, but a floated one.

If you swap in these values:

URL = "http://www.bing.com"
tag_id = "sbox"

(That's the search box on bing.com)

You'll get a value for left because it's a positioned element.

I think the best you can do is to get the offsetParent of the element. That's the closest parent element in the DOM that is postioned. It's stored as a property called offsetParent.

You can pass that to the getComputedStyle method and get information for it.

If you really, really need the position you could perhaps go through trouble of estimating it by reading out margins and padding for the elements in between your target element and the offsetParent and adding them to get the possible position? (I believe that's how it's done by jQuery internally).

~Micheal



hdsouza

Yes, I see what you mean. Thanks Mike
Ever tried getBoundingClientRect as in http://javascript.info/tutorial/coordinates (bottom of page)
Maybe it will get the position of a floated element?
I am having a real problem getting winbatch to run with this new code

mhall

I haven't actually used getBoundingClientRect, but when I was looking for ideas, I was looking at the jQuery code at a method called offset which will return positions for floated elements and that is part of the method they use.

I did a little more poking around and think I've come up with a way that works using getBoundingClientRect. The most frustrating thing is working out how to call the methods from WinBatch. I feel stupid every time I start poking at it. :o

But, is seems that you need to call getBoundingClientRect as a method of the dom_object you want the position for ... but you also need to pass that method the reference to the dom_object. See if this gives you the data you are looking for:



URL = "http://www.winbatch.com/techsupt.html"
tag_id = "inpagelinks"

Browser           = ObjectCreate("InternetExplorer.Application")
browser.visible   = @TRUE
browser.navigate( URL )
while browser.readystate <> 4
       timedelay(0.5)
endwhile

BrowserDoc    = browser.Document
BrowserBody   = BrowserDoc.Body
BrowserPage   = BrowserBody.CreateTextRange
BrowserText   = BrowserPage.Text

dom_element   = BrowserDoc.getElementById( tag_id )
position      = dom_element.getBoundingClientRect( dom_element )

message( 'coords', position.top:@CRLF:position.left:@CRLF:position.bottom:@CRLF:position.right )

exit



td

'GetBoundingClientRect' is a method of MSFT's 'DispHTMLAnchorElement' COM interface.  Basically, it means it is a method that can be called on anchor elements. 

The WIL Type Viewer is a handy tool for finding out how DOM methods and attributes translate from the DOM to MSFT's COM Automation version of same.   Go to the 'Viewer' tab, type 'htmlfile' in the combo box and click the 'Get Library' button. This will load all of the COM Automation interfaces, enumerations, and classes associated with the DOM.  If you right-click on 'htmlfile' in the tree view control at the left and then click the 'Expand All' context menu, you can search for a specific item in the library. Simply right-click again and select the 'Find...' menu item to display the find dialog, enter your search term and click the 'Find Next' button.

Admittedly, the naming conventions use by MSFT take some getting use to but it doesn't take to long to get a feel for how it all fits together.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

hdsouza

Quote from: mhall on December 14, 2014, 02:47:48 PM
I haven't actually used getBoundingClientRect, but when I was looking for ideas, I was looking at the jQuery code at a method called offset which will return positions for floated elements and that is part of the method they use.

I did a little more poking around and think I've come up with a way that works using getBoundingClientRect. The most frustrating thing is working out how to call the methods from WinBatch. I feel stupid every time I start poking at it. :o

But, is seems that you need to call getBoundingClientRect as a method of the dom_object you want the position for ... but you also need to pass that method the reference to the dom_object. See if this gives you the data you are looking for:

Hi Mike,
yes the coordinates are visible now although they appear to be skewed to the Right and Bottom

I am thinking we may need a scrollTop and ClientTop  to be added
I tried to get the scrollTop (as in http://javascript.info/tutorial/coordinates )  but the code breaks on window.pageYOffset

Code (winbatch) Select


URL = "http://www.winbatch.com/techsupt.html"
tag_id = "inpagelinks"

GoSub Open_IE

GoSub Highlight_Selection
GoSub Get_Coordinates
exit
;*******************
:Get_Coordinates
Browser_Name = strtrim(msie.Document.title)
dom_element   = msie.Document.getElementById( tag_id )
position      = dom_element.getBoundingClientRect( dom_element )

Pos_top = itemextract(1, position.top, ".")
Pos_left = itemextract(1, position.left, ".")
Pos_bottom = itemextract(1, position.bottom, ".")
Pos_right = itemextract(1, position.right, ".")

MousePlay("%Pos_left% %Pos_top%", Browser_Name, "", 0, 0.5)
timedelay(0.2)
MousePlay("%Pos_left% %Pos_bottom%", Browser_Name, "", 0, 0.5)
timedelay(0.2)
MousePlay("%Pos_right% %Pos_bottom%", Browser_Name, "", 0, 0.5)
timedelay(0.2)
MousePlay("%Pos_right% %Pos_top%", Browser_Name, "", 0, 0.5)
Return
;*******************
:Open_IE
msie           = ObjectCreate("InternetExplorer.Application")
msie.visible   = @TRUE
msie.navigate( URL )
TIMEDELAY(5)
while msie.readystate <> 4
       timedelay(0.5)
endwhile
Return
;*******************
:Highlight_Selection
ForEach Div in msie.document.GetElementsByTagName("Div")
   if strtrim(div.ID) != tag_id then Continue
   div.style.border = ".25mm solid red"
   Break
Next
Return
;*******************


td

The DOM method returns coordinates in pixels but MousePlay expects virtual coordinates.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

hdsouza

Quote from: td on December 15, 2014, 10:50:09 AM
The DOM method returns coordinates in pixels but MousePlay expects virtual coordinates.

So what is the syntax to convert pixels to mouse co-ordinates?
Lets say I want to move the mouse to the top of the DIV

td

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

hdsouza

Quote from: td on December 15, 2014, 01:25:47 PM
The handy-dandy Tech Database is always at your service.

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+Tutorials+Screen~Coordinates~Explained.txt


The dimensions are a lot better now, although its skewed to the LEFT by a negligible amount and to the TOP by quite a bit.
Is that the Control bar(Address bar/menu bar/tool bar) at the top of IE acting up and if so how do we get the height of the control bar

Code (winbatch) Select


URL = "http://www.winbatch.com/techsupt.html"
tag_id = "inpagelinks"

GoSub Open_IE
GoSub Highlight_Selection
GoSub Get_Coordinates
exit
;*******************
:Get_Coordinates
Browser_Name = strtrim(msie.Document.title)
dom_element   = msie.Document.getElementById( tag_id )
position      = dom_element.getBoundingClientRect( dom_element )

Pix_left = itemextract(1, position.left, ".")
Pix_top = itemextract(1, position.top, ".")
Pix_right = itemextract(1, position.right, ".")
Pix_bottom = itemextract(1, position.bottom, ".")

; Converting Pixels to Coordinates
XY_left  = DllCall(DirWindows(1):"kernel32.dll",long:"MulDiv",long:Pix_left,long:1000,long:WinMetrics(0))
XY_top = DllCall(DirWindows(1):"kernel32.dll",long:"MulDiv",long:Pix_top,long:1000,long:WinMetrics(1))
XY_right = DllCall(DirWindows(1):"kernel32.dll",long:"MulDiv",long:Pix_right,long:1000,long:WinMetrics(0))
XY_bottom = DllCall(DirWindows(1):"kernel32.dll",long:"MulDiv",long:Pix_bottom,long:1000,long:WinMetrics(1))

; Verifying Coordinates with a mouse trace
MousePlay("%XY_left% %XY_top%", WinIE_ID, "", 0, 0.5)
timedelay(0.2)
MousePlay("%XY_left% %XY_bottom%", WinIE_ID, "", 0, 0.5)
timedelay(0.2)
MousePlay("%XY_right% %XY_bottom%", WinIE_ID, "", 0, 0.5)
timedelay(0.2)
MousePlay("%XY_right% %XY_top%", WinIE_ID, "", 0, 0.5)
Return
;*******************
:Open_IE
msie           = ObjectCreate("InternetExplorer.Application")
msie.visible   = @TRUE
msie.navigate( URL )
TIMEDELAY(5)
while msie.readystate <> 4
       timedelay(0.5)
endwhile
Return
;*******************
:Highlight_Selection
ForEach Div in msie.document.GetElementsByTagName("Div")
   if strtrim(div.ID) != tag_id then Continue
   div.style.border = ".25mm solid red"
   Break
Next
Return
;*******************

td

Given your description of the returned coordinates, 'getBoundingClientRect' is possibly returning coordinates relative to IE's client area.  If so, this means you would need to convert the returned coordinates to screen coordinates.  From there you could either just convert them to virtual coordinates and not use IE as the second parameter to MousePlay or you could map the screen coordinates to IE's window rectangle coordinates and continue to use IE as the second parameter to MousePlay. MSFT provides several function for mapping window coordinates so one or more DllCall would be in order. 'ClientToScreen' and 'MapWindowPoints' are to Win32 function that you might find useful in this endeavor.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

hdsouza

Quote from: td on December 16, 2014, 08:12:57 AM
Given you description of the returned coordinates, 'getBoundingClientRect' is possibly returning coordinates relative to IE's client area.  If so, this means you would need to convert the returned coordinates to screen coordinates.  From there you could either just convert them to virtual coordinates and not use IE as the second parameter to MousePlay or you could map the screen coordinates to IE's window rectangle coordinates and continue to use IE as the second parameter to MousePlay. MSFT provides several function for mapping window coordinates so one or more DllCall would be in order. 'ClientToScreen' and 'MapWindowPoints' are to Win32 function that you might find useful in this endeavor.

Not sure what this means. I was already able to convert the pixels to mouse coordinates. If I am not able to send a mouse move to IE then the objective of the exercise is lost. Is there no way to find the dimensions of an element on a webpage.
I even tried MapWindowPoints as suggested but got an error
AA = dllcall(user32,long:"MapWindowPoints",long:"MulDiv",long:HWND_DESKTOP,lpbinary:RECT,long:2)

td

MousePlay does not send mouse coordinates to a Window.  It send the mouse location to the mouse device driver.  The only purpose of supplying a window name to MousePlay is to tell it that the input coordinates relative to the origin of that window instead of relative to the origin of the screen.   

You script takes the coordinates returned by the 'getBoundingClientRect' method and converts them from pixels to virtual screen coordinates.   You then pass them to MousePlay with a window name so that Mouse play will move the mouse to a position relative to the window origin instead of the screen origin. 

The problem with this is that 'getBoundingClientRect' does not return coordinates relative to the IE main window origin.  It returns coordinates relative to some child window's origin.   That is why your mouse cursor placement is off by the difference between the IE main window origin and whatever child window's origin.

You are going to have to figure out how to map the returned coordinates to the correct window or to the screen.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

hdsouza

Quote from: td on December 16, 2014, 03:26:06 PM
MousePlay does not send mouse coordinates to a Window.  It send the mouse location to the mouse device driver.  The only purpose of supplying a window name to MousePlay is to tell it that the input coordinates relative to the origin of that window instead of relative to the origin of the screen.   

You script takes the coordinates returned by the 'getBoundingClientRect' method and converts them from pixels to virtual screen coordinates.   You then pass them to MousePlay with a window name so that Mouse play will move the mouse to a position relative to the window origin instead of the screen origin. 

The problem with this is that 'getBoundingClientRect' does not return coordinates relative to the IE main window origin.  It returns coordinates relative to some child window's origin.   That is why your mouse cursor placement is off by the difference between the IE main window origin and whatever child window's origin.

You are going to have to figure out how to map the returned coordinates to correct window or to the screen.

TD, this is what I mentioned in my previous post on December 15, 2014, 12:30:51 pm.  There is a scroll top and Client top component to be added/subtracted.
Now I am able to get the scroll top

Code (winbatch) Select

scrollTop = msie.document.documentElement.scrollTop
scrollLeft = msie.document.documentElement.scrollLeft


But I have racked my brains on the client top as described on this page http://javascript.info/tutorial/coordinates but cannot figure it out
Thanks

td

My point was that it is likely just a Windows window.  You probably could even use Roboscripter to figure out how to get a handle to the IE child window you need.  Once you have that you could just need to map the coordinates, if using MousePlay is your goal.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

mhall

So you need the screen coordinates (not the page coordinates) of the click, right?

Does it sounds right that you need the

browser_window.x + browser_window_toolbar.width + click.x
browser_window.y + browser_window_toolbar.height + click.y

That seems like it would get you the x,y coordinates you can then translate into something else.

If so ... the full browser window width and height are available via the window.outerWidth and window.outerHeight properties.

http://www.w3schools.com/jsref/prop_win_outerheight.asp

The display area dimensions are available via window.innerHeight and window.innerWidth.

http://www.w3schools.com/jsref/prop_win_innerheight.asp

You can subtract the innerHeight from outerHeight and innerWidth from outerWidth to get the toolbar dimensions.

Then, presumably, you can get the x,y coordinates of the browser window via WinBatch and add everything together to get the coordinates you need.

I tried accessing the .outerHeight properties quickly via ...



URL = "http://www.winbatch.com/techsupt.html"
tag_id = "inpagelinks"

Browser           = ObjectCreate("InternetExplorer.Application")
browser.visible   = @TRUE
browser.navigate( URL )
while browser.readystate <> 4
       timedelay(0.5)
endwhile

BrowserDoc    = browser.Document
BrowserBody   = BrowserDoc.Body

message( '', BrowserDoc.parentWindow.outerHeight )


exit



The good news is that I got values out.

The bad news is that, in MSIE, they don't seem accurate (they didn't match the size of my browser window). However, when I get the values via Firefox (using some Javascript on a simple page and accessing window.outerWidth/window.outerHeight) they match perfectly. According to the above links, MSIE offers full support of the methods since version 9 and I have 11 here, so they should be working.

I don't know why they aren't, but perhaps you can have a play with that and see if you can get something out of it.

~Micheal

hdsouza

Quote from: mhall on December 16, 2014, 10:29:55 PM
So you need the screen coordinates (not the page coordinates) of the click, right?

Does it sounds right that you need the

browser_window.x + browser_window_toolbar.width + click.x
browser_window.y + browser_window_toolbar.height + click.y

That seems like it would get you the x,y coordinates you can then translate into something else.

If so ... the full browser window width and height are available via the window.outerWidth and window.outerHeight properties.

http://www.w3schools.com/jsref/prop_win_outerheight.asp

The display area dimensions are available via window.innerHeight and window.innerWidth.

http://www.w3schools.com/jsref/prop_win_innerheight.asp

You can subtract the innerHeight from outerHeight and innerWidth from outerWidth to get the toolbar dimensions.

Then, presumably, you can get the x,y coordinates of the browser window via WinBatch and add everything together to get the coordinates you need.

I tried accessing the .outerHeight properties quickly via ...



URL = "http://www.winbatch.com/techsupt.html"
tag_id = "inpagelinks"

Browser           = ObjectCreate("InternetExplorer.Application")
browser.visible   = @TRUE
browser.navigate( URL )
while browser.readystate <> 4
       timedelay(0.5)
endwhile

BrowserDoc    = browser.Document
BrowserBody   = BrowserDoc.Body

message( '', BrowserDoc.parentWindow.outerHeight )


exit



~Micheal

Thanks Mike, I ran the code as is and I get an error on line : message( '', BrowserDoc.parentWindow.outerHeight )
Tried on two different systems on ie11 I get "access denied". On ie9 I get "OLE: unknown name"
I noticed you computed BrowserBody in your code. Where you planning to use it in getting the height

mhall

Hmmm, that's odd. I've run it successfully on both a Win7 and Win8 machine.

The BrowserBody line is one I forgot to take out when I was trimming things down.

It is strange though - I cannot put window.outerHeight into a simple HTML page and run it on a local webserver and get IE to give me a value back. I get an undefined. I've tried messing with browser script security settings (there are several IE settings related to window size), and haven't had any luck. I've also tried the older, non-standard methods from pre-IE 9 and they aren't working either. So I can get a value (albeit incorrect) running that WinBatch code, or I get no value trying to insert it into a local page and running that in IE.

In Firefox window.outerWidth runs fine.  :-\

But according to MS, it should work:

http://msdn.microsoft.com/en-us/library/ie/ff974682%28v=vs.85%29.aspx


So, just out of curiosity ... what were you trying to do with all of this again? Just wondering if there might be another approach ...

hdsouza

Mike, When you mentioned it worked on win7 and win8 was that with Winbatch or Java script. There was also a mention of firefox  and I know that winbatch does not work with firefox. So I just wanted to clarify

My objective was to get to the elements in an iframe. Had a long discussion on that topic here http://forum.winbatch.com/index.php?topic=1181.0. Since there was no resolution I was attempting to use mouse clicks to get to the elements in an iframe. That's why i need to get the position of an element. It would be crude but still doable

Thanks for your help

hdsouza

Quote from: td on December 16, 2014, 07:58:33 PM
My point was that it is likely just a Windows window.  You probably could even use Roboscripter to figure out how to get a handle to the IE child window you need.  Once you have that you could just need to map the coordinates, if using MousePlay is your goal.

Td, I tried roboscriter, but it does not find any components on the webpage.
If you have a way of getting roboscripter to show the coordinates of the element on a webpage, please let us know how to do it

td

I didn't convey the suggestion very clearly. You have a set of coordinates for an HTML element via getBoundingClientRect and you know how to convert them to the WIL virtual 1000 X 1000 coordinate plan.   You know how to convert coordinates from one window's coordinate plan to another window's coordinate plan or the desktop using a DllCall to MapWindowPoints or ClientToScreen.  The problem seems to be that you can't convert  the coordinates returned by  getBoundingClientRect to desktop or windows coordinates because you don't know what the  getBoundingClientRect coordinates are relative to.   The idea was that the getBoundingClientRect coordinates are relative to the IE child window displaying the page so you could use Control Manager (Roboscripter generated script) to obtain the handle to the IE child window and use it to do the needed conversion after adjusting the getBoundingClientRect coordinates for the scrollbars.

However, after giving it some thought, the idea is probably far to Rube Goldbergian to be very useful.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

The following script modification is too dependent on system and browser settings along with versions of both to be of any practical use.  Mostly just wanted to see if it could be done
Code (winbatch) Select

AddExtender("wwctl44i.dll")

URL = "http://www.winbatch.com/techsupt.html"
tag_id = "inpagelinks";'content'
GoSub Open_IE
GoSub Highlight_Selection
GoSub Get_Coordinates

exit

;*******************
:Open_IE
msie           = ObjectCreate("InternetExplorer.Application")
msie.visible   = @TRUE
msie.navigate( URL )
TIMEDELAY(5)
while msie.readystate <> 4
       timedelay(0.5)
endwhile
Return

;*******************
:Highlight_Selection
;return
ForEach Div in msie.document.GetElementsByTagName("Div")
   if strtrim(div.ID) != tag_id then Continue
   div.style.border = ".25mm solid red"
   Break
Next
Return

;*******************
:Get_Coordinates
;Browser_Name = strtrim(msie.Document.title)
dom_element   = msie.Document.getElementById(tag_id)

; Adjust for zoom  (80000 is 100%)
zFactor = RegQueryDword(@REGCURRENT, 'Software\Microsoft\Internet Explorer\Zoom[ZoomFactor]')/80000.0
Pix_left = dom_element.offsetLeft*zFactor
Pix_top = dom_element.offsetTop*zFactor

; Convert from client to screen
hWnd = msie.HWND
WinActivate(cWinIdConvert(hWnd))
hWnd2=cWndBySeq(hWnd,5) ; NOTE! 6 with Explorer bar 5 without - means registry check here.
hWnd3=cWndByName(hWnd2,`WinBatch - Technical Support - Internet Explorer~`)
hWnd4=cWndByID(hWnd3,0)
hWnd5=cWndByID(hWnd4,0)

strPoint = "int:x;int:y"
hPoint = DllStructAlloc(strPoint)
DllStructPoke(hPoint, 'x',Pix_left)
DllStructPoke(hPoint, 'y',Pix_top)

;DllCall('user32.dll',long:'ClientToScreen',long:hWnd5, lpstruct:hPoint)
DllCall('user32.dll',long:'MapWindowPoints',long:hWnd5, lpnull, lpstruct:hPoint, long:1)

Pix_left = DllStructPeek(hPoint, 'x')
Pix_top  = DllStructPeek(hPoint, 'y')
DllStructFree(hPoint)

; Convert from screen to virtual
XY_left  = DllCall("kernel32.dll",long:"MulDiv",long:Pix_left,long:1000,long:WinMetrics(0))
XY_top = DllCall("kernel32.dll",long:"MulDiv",long:Pix_top,long:1000,long:WinMetrics(1))

; Whatever
MousePlay("%XY_left% %XY_top%",'' , "", 0, 0.5)       
return


"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

hdsouza

Quote from: td on December 23, 2014, 03:02:52 PM
The following script modification is too dependent on system and browser settings along with versions of both to be of any practical use.  Mostly just wanted to see if it could be done

I am guessing I would need winbatch 2014 for this. correct?. In either case I have just placed a new order for 2014. 
Will update on the code, once supports sends me the new keys

td

The only part of the script that requires 2014B is the use of the DllStruct* functions.  You can do the same thing with Binary* functions but Binary* functions take a little more thought. 

I confess that I tend to post scripts on this forum that use the latest releases' enhancements.  This is not so much to induce users to upgrade but simple because new features and enhancements tend to make a script easier to create.   
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

DAG_P6

Quote from: td on December 23, 2014, 03:02:52 PM
The following script modification is too dependent on system and browser settings along with versions of both to be of any practical use.  Mostly just wanted to see if it could be done

That thought kept running through my head as I scanned this thread. The reason that there isn't a direct way to get the coordinates of any HTML element is that they are largely dependent upon the properties of the window in which it is rendered. After all, HTML is a fairly high level declarative abstraction of how the page is to be rendered. Hence, a great deal is left to the discretion of the user agent (Internet Explorer, Fierfox, Chrome, Opera, Safari, Lynx, etc.). Even given the same system settings (e. g., screen resolution and window dimensions), it is almost certain that no two Web browsers will render the same page in exactly the same way, even if you confine yourself to HTML 2.0 entities.
David A. Gray
You are more important than any technology.

hdsouza

Quote from: td on December 24, 2014, 10:41:39 AM
The only part of the script that requires 2014B is the use of the DllStruct* functions.  You can do the same thing with Binary* functions but Binary* functions take a little more thought. 

I confess that I tend to post scripts on this forum that use the latest releases' enhancements.  This is not so much to induce users to upgrade but simple because new features and enhancements tend to make a script easier to create.

Unfortunately it did not work.  the code lands the cursor on the middle bottom of the div instead of the top left
Also the zFactor in the code skews things up even more
Maybe the code on December 15, 2014, 05:56:52 pm worked  better
Any plans of getting winbatch to work with Firefox?

stanl

Quote from: hdsouza on December 27, 2014, 06:40:41 PM
Any plans of getting winbatch to work with Firefox?

You can check this out. Not sure if the original project went any further than the basics of wrapping IE functions. It probably won't apply to your issues on this thread, but this route is the only thing I can think of that comes close to allowing WB to work directly with Firefox, although WB can work with PHP and that may be a possible route.

http://www.iol.ie/~locka/mozilla/control.htm

td

Quote from: hdsouza on December 27, 2014, 06:40:41 PM
Unfortunately it did not work.  the code lands the cursor on the middle bottom of the div instead of the top left
Also the zFactor in the code skews things up even more
Maybe the code on December 15, 2014, 05:56:52 pm worked  better
Any plans of getting winbatch to work with Firefox?

The script works perfectly on my Windows 7 workstation given the current IE settings on the system.  If it doesn't work for you then it is likely a matter of adjusting for different IE settings, given the willingness to waste the time necessary to adapt it to a site and IE/System settings.

There are no plans to make WinBatch 'work' with Firefox. Firefox is open source and any effort that involved using that source would need to be initiated by that community because of licensing issues. Also, any such effort would not be a cure-all for the underlying fundamental problems inherent in attempting to automate web sites using the DOM.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade