Jump to content
Sign in to follow this  
jfred

Bring hidden active window forward

Recommended Posts

Melba23

jfred,

It was designed so that the end user had to click on the print button/icon to get the report to print

So now you have managed to get "the "print report" option window to open for printing" can you not just use MouseClick to simulate pressing the button on it? :x

You may need to do a bit of maths to get the coordinates right, but if there is a GUI button to click AutoIt ought to be able to click it. :P

M23


Public_Domain.png.2d871819fcb9957cf44f4514551a2935.png Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind

Open spoiler to see my UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites
jfred

I guess that could be possible. The issue I see there is if the window size does not remain the same, the print button may not get clicked.

I will check out your suggestion over the next couple of days, and let you know what happens.

Thanks

Share this post


Link to post
Share on other sites
rover

you haven't mentioned what worked - post the results of the code I gave you with the consolewrites.

as for the print dialog, I wouldn't give up so soon

you say this is another application, therefore you can get the process name from taskmgr as you did for the previous dialog

it has the same class as the previous window: ThunderForm

therefore you can use the previous code I posted (WinList()) to get the correct window handle by comparing WinGetProcess() to the process name

and it has an Afx class child dialog, same as previous window... AfxWnd / AfxControlBar

AfxControlBar instance 1 has an ID of 59392, you can use that with _WinAPI_GetDlgItem (ThunderForm handle, 59392)

to get the handle to instance 1 (if that dialog has more than one AfxControlBar instance)

or use ControlGetHandle(ThunderForm handle, "[CLASS:AfxControlBar; INSTANCE:1]").

without seeing a screenshot, I assume the target button is on that AfxControlBar child dialog of the Thunderform class window.

use Ascendant's or Yashied's enumerate all child windows functions to search for all controls of that dialog

see also _WinGetCtrlInfo() below

use other windows tools such as Winspector Spy, Window Detective, RanorexSpy, Spy++ etc.

and see if controls become visible, there are some dialogs that the AutoIt window tool does not read correctly.

some links to those tools here:

at minimum with the window handle, you can get the window co-ordinates of the print dialog for a 'reliable' mouse click on the button.

try and get that thunderform window handle and the AfxControlBar handle.

if you get that far then try enumeration of the controls for both handles.

more control enumeration code:

the thread with Larry's enumerate control IDs code, was archived or destroyed by the forum software.

but SmoKe_N's _WinGetCtrlInfo() is an update of that code.

http://www.autoitscript.com/forum/index.php?showtopic=32781

for a given window it returns an array of control class/instance and ID, but does not include handles

it can be easily modified to include handles in the array


I see fascists...

Share this post


Link to post
Share on other sites
jfred

Since being a newb at this and been working on this script for almost 2 months, (in between other duties), it has been frustrating.

Well have taken all suggestions in and working on it as time permits. So I have been able to get the script to work all the way to the end, (stalls once in awhile over all runs through all the way).

I have cleaned up all testing lines and what not, to keep the visual scripting pollution to a minimum for myself.

Here is the final script that seems to work (I'm sure it could be cleaned up and with different syntax/strings):

Run("K:\CFAWIN\CFAWin.exe")

WinWaitActive("CFAWin v.7.0.1065")

Sleep(71000)

WinWaitActive("Select Company/Organization and Login")

Send("User")

Send("{TAB}")

Send("PassW")

Send("{TAB}")

Send("{SPACE}")

;CFA home page

WinWaitActive("CFAWin v.7.0.1065 (Profile: VOG)", "")

Sleep(220000)

WinWaitActive("CFAWin v.7.0.1065 (Profile: VOG)", "")

Send("{ShiftDown}")

Send("{F6}")

Send("{ShiftUp}")

WinWaitActive("CFAWin v.7.0.1065 (Profile: VOG) - [Fuel/Fluid/Meter Entry]", "")

Sleep(120000)

;Fuel inventory import

WinWaitActive("CFAWin v.7.0.1065 (Profile: VOG) - [Fuel/Fluid/Meter Entry]", "")

Send("{ALTDOWN}")

Send("{5}")

Send("{ALTUP}")

Send("{F5}")

Sleep(15000)

;Get to Fuel Transaction window (No active title bar information hidden active window)

Send("{ALTDOWN}")

Send("{TAB}")

Send("{ALTUP}")

;Access Print for the first fuel error report

;Send("{TAB}")

;Send("{SPACE}")

MouseClick("left", 680, 761, 1)

Sleep(10000)

WinWaitActive("Q:\CFAWIN\DATA\EQFAFUEL.RPT","")

MouseClick("left", 275, 65, 1)

Sleep(5000)

;Print error report

WinWaitActive("Print", "")

Send("{ENTER}")

;Close Report print preview window

Sleep(40000)

WinWaitActive("Q:\CFAWIN\DATA\EQFAFUEL.RPT","")

MouseClick("left", 1670, 11, 1)

;Sleep(10000)

;Import Fuel data ******DON"T FORGET REPRINT OF FUEL REPORT AFTER FUEL DATA IMPORT AND REPORT AGAIN********

;MouseClick("left", 605, 413, 1)

;Send("{TAB}")

;Send("{TAB}")

;Send("{SPACE}")

;Exit "CFAWin96", "Current Fuel Transaction"

MouseClick("left", 1121, 962, 1)

;Exit CFAWin v.7.0.1065 (Profile: VOG) - [Fuel/Fluid/Meter Entry]

WinWaitActive("CFAWin v.7.0.1065 (Profile: VOG) - [Fuel/Fluid/Meter Entry]", "")

MouseClick("left", 32, 34, 1)

Send("{Down 8}")

Send("{ENTER}")

Sleep(10000)

;Exit CFAWin v.7.0.1065 (Profile: VOG)

WinWaitActive("CFAWin v.7.0.1065 (Profile: VOG)", "")

MouseClick("left", 11, 34, 1)

Send("{DOWN 8}")

Send("{ENTER}")

;Sleep(5000)

;End session, exit app.

WinWaitActive("Application Message")

Send("{SPACE}")

So there it is.

The other draw back I have found using this script, is if the screen resolution changes and/or some other action happens while the script is running. Hopefully these draw backs will not happen, since this is planned to run as a task before anyone gets to their desk that have CFA installed on their workstation.

Share this post


Link to post
Share on other sites
jfred

Rover I know my previous post to this one, has no information from the last script you posted for me. Before I saw the script I was looking at the mouse x/y information that was listed in the INFO-Tool.

I started to play with this prior to the last script you posted, and worked the mouse x/y into my script. Which seems to work.

If you wish I can run the last script you posted and let you know what the results are.

Share this post


Link to post
Share on other sites
jfred

OK so I have posted a bit soon to a degree that it works or being the final script.

In my VM with the screen resolution set like the CFA users, the script and the app run as expected.

Now after compiling the script to a .EXE, it will bring the hidden window (CFA 96) forward, and then instead of activating the print button, the previous window opens/brought forward again.

From there if the CFA 96/hidden window tab is clicked and then print is clicked, the report will print most of the time (sometimes OK has to be clicked), the script continues to close the print preview window and then the script will finish as it should closing CFA.

So not sure what is going on there. Back to the drawing board!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×