Dynamically Change HTA Window Properties - dom

In my HTA, I hold it it open if an error occurred, and close it if everything was successful. At the start, I have the sysmenu property set to no because I do not want the user to close the HTA until it's finished. At the end, I want them to be able to click on the close button. Here's what I typed up to try to achieve this, but it doesn't seem to work? I suspect there is something I need to do to get the HTA to refresh it's windows properties?
Please note that any solution that completely reloads the window and/or makes the script execute again is not acceptable
If Not bHoldOpen Then
Call window.close
Else
Dim tagHTA
Set tagHTA = document.getElementsByTagName("hta:application").item(0)
Call tagHTA.setAttribute("sysmenu","yes")
End If

You cannot change it at runtime, its only available in the HTA: block as its value is used to determine how the physical window is to be initially created.
I thought you could produce a warning using the onBeforeUnload event & call cancelBubble to abort the close, but I tried it in IE8 and it still seems bugged; http://support.microsoft.com/kb/946214.
It would probably be simpler and easier for the user to comprehend if you were yo just unhide a "Close" button when the process completed.

Related

Issue with setting AutomationElement value

I have an issue with setting value of AutomationElement by using method ValuePattern.SetValue().
Everything works just fine until some dialog appears. When the dialog appears the code execution got stuck. No exception is thrown. After the dialog is confirmed, the code exection continues. Bellow is a sample of the code:
BasePattern basePattern = null;
ValuePattern valuePattern = null;
AutomationElement elementA = Window.GetElement(SearchCriteria.ByText(propertyName));
object patternObjectA = null;
elementA.TryGetCurrentPattern(ValuePattern.Pattern, out patternObjectA);
basePattern = (BasePattern)patternObjectA;
valuePattern = (ValuePattern)patternObjectA;
valuePattern.SetValue(optionToSet);
// Window.GetElement() is a method from TestStack.White framework
// The code execution got stuck on the last line until the dialog is confirmed
Is there any other way to set AutomationElement value?
Is somehow possible to avoid of getting stuck by dialog?
I'll by grateful for any help.
Thanks advance.
It could be that this dialog is not supporting UI Automation correctly or that you simply target the wrong element.
To verify that you may use Inspect.exe from Microsoft or similiar tools.
If it works, check if you really target the correct component with your code again.
If it does not work and:
if you are able to change the application
you can change the so called AutomationPeer of the UI component - here is a link for more infos
Or simply use another UI component that supports UI Automation correctly.
if you are not able to change the application, and also do not need to run in background, parallel, etc.. you might just focus the component (call setFocus() onto the AutomationElement, or expand it (via IsExpandCollapsePatternAvailable or simulated MouseClick onto the components coordinates)) and then use the SendKeys.SendWait("test") method.
EDIT: There is one more thing you should have a look at, and I wonder why I didn't mentioned it in the first place: Register to UI Automation Events
For example you could register a callback for the Structure change event type, and check if the dialog you talk about appeared.
If so --> click the confirmed button of the dialog.
Probably you will have to synchronize your execution, so that every further action in the UI Automation script waits until the registered callback got executed and the confirmed button got clicked.

Programmatic Method of Handling Matlab Dialog Windows

I have a rather large Matlab program that is GUI based. I am looking into creating automated tests for it, as the current way of checking for bugs before a release is simply using all its functionality like a user would.
I would rather not use a GUI testing program that just records clicks and what not, so I was thinking of adding testing code that would call the button callbacks directly. The problem that I have run into with this is that we have a lot of warndlg and msgbox popups, and I would like my tester code to be able to see these.
Is there any way for Matlab code to tell if a function it called created a warndlg or msgbox? If so, is there any way to click 'ok' on these popups?
In a similar vein, is it possible to handle popups that block code execution (using uiwait or an inputdlg)?
If it matters I didn't use GUIDE, and all the GUI elements are created programmatically
Two ways. The first one is more elegant
Let the functions return an extra variable and return the status of the function. For example, 1: success, 2: success with warning, 3: error...
Create some global variables and make the function change them if a warndlg or msbgbox shows up. The main window would then check if the status of the global variable.
You can tell if a warning dialog was created by looking for it's tag using the findobj function. A warning dialog created using warndlg will have the tag "Msgbox_Warning Dialog". So code like this would tell you if the warning dialog exists:
set(0,'ShowHiddenHandles', 'on')
h = findobj('Tag', 'Msgbox_Warning Dialog');
warn_exists = ~isempty(h)
set(0,'ShowHiddenHandles', 'off')
to close the warning dialog, you can call delete, like this:
delete(h)
For the message box, I would store the handle when you create a message box, then look at the children to find the buttons, then look at their callbacks. You should be able to call the callbacks to simulate picking a button.

How to block GUI while function with output executes?

I am creating a MATLAB application in GUIDE and now I'm facing a problem. I need to call a function that takes a long time to execute and returns a value but while executing the function I want the GUI to wait for the returned value.
I tried with waitfor but this way I can still interact with the GUI and I can't take the returned value...
waitfor(function);
I can think of something that disables all the GUI then enables it back but I have both enabled and disabled objects...
Do you know any solution to this problem?
A simple solution is to create a modal dialog box with a message "Please wait..." just before executing your long-running function, and then to close the dialog box just after it completes. A modal dialog will be in front of the GUI, and will not allow interactions with the window behind.
It's possible for the user to click the "Close" button on the dialog, but you can override this by setting the "CloseRequestFcn" property of the dialog, so that the close button does nothing (unfortunately you can't easily hide the button).
I like the modal dialog proposed by Sam Roberts. There is no mystery and it is user friendly.
Another dirty and easy solution may be to hide the GUI completely, if it is okay:
set(hFig, 'Visible', 'off');
And set it to 'on' after done. It will be good practice to make sure to set it to 'on' in catch block, to avoid disappearing GUI due to error during execution.

DOM usage in QTP

During script execution a pop up won't go away, and it happens only through QTP(v12.02).
I am trying DOM to bypass the problem, the pop up event was on selection of a drop down value, so I used some code to find the correct index and use DOM to select the value
Browser().Page().WebList().Object.selectedIndex = itmindx
With this the pop up issue got resolved, but now to complete the process,I need to click the Save button which is disabled as the page didn't refreshed when the value was selected ( tried refreshing through QTP, tab out etc--didn't worked as it loads the previous value).So I used the fire event method
Browser().Page().WebList().Fireevent "onchange"
with this I ran in to the same issue of multiple pop ups. Used the following
Browser().Page().WebList().Object.onchange()
but then QTP won't executes the next line unless I hit enter externally on the pop up(multiple pop up is resovled but now QTP is stuck. I don't want to use RS.... Any solutions?
To enable the button
Browser().Page().WebButton().Object.disabled = false
Or
To hit enter for the popup
CreateObject("WScript.Shell").SendKeys("{ENTER}")
[ http://ss64.com/vb/sendkeys.html ]
Go for hitting the Enter button using SendKeys. It is not a good idea accessing DOM and change the state ourselves. There is a chance that you might miss potential defects!

Access Pop Up Form Background Garbled/Distorted When Opened via OpenForm Macro Action with Window Mode Normal

I have a database that I work on using Access 2013, though I must maintain compatibility with Access 2010; I am using Windows 7.
I have an input form that is set to Pop Up = Yes, and Modal = No. When opening this input form directly from the Navigation Pane, it functions perfectly normally.
I have a macro in a search form that calls up this input form with the specified record using the "OpenForm" action. When opening the input form with this macro, the form's background is totally garbled (it pulls the background image from whatever was behind it when called, as though it were transparent), and all labels are unreadable.
That said, if I run the macro again by trying to open a different record, the form then appears correctly until it is closed. Also, if I change the "Window Mode" in the "OpenForm" action to "Dialog" rather than "Normal," it appears correctly.
Neither of these are valid solutions, though -- it should work on the first time, and I do not want the form to be modal. All my code seems okay (insomuch as I am not receiving error messages), so I don't understand why it would be doing this... any guidance is very much appreciated.
I have discovered what is causing this problem, though I don't understand why.
The macro I am using came from a sample database, and has some commands I am not fully familiar with. One such command is "Requery."
I experimented with removing various parts of the macro with the window mode as "Normal" for the "OpenForm" command. As soon as I tried removing "Requery" (and nothing else) the window opened in "Normal" mode with no distortion whatsoever.
In short, having "Requery" in the macro was what was causing this error to occur. It seems like an innocuous enough action (all it does is refresh data, from what I understand, as described here: https://msdn.microsoft.com/en-us/library/bb177360(v=office.12).aspx), but since I don't see why its inclusion was necessary anyway (if anyone could shed some light on that, it would be appreciated), it looks like this is essentially solved.
I hope this may help someone else in the future!