I have a powershell script with a simple form which is working. It runs an external application (USMT scanstate / loadstate) and the functionality is all fine.
However when it's running the user has no feedback that it is working, so initial users were thinking something had gone wrong.
I've added a marquee progress bar to run at the bottom of the form to indicate it is working.
I can use the:
$progressbar1.visible = $False
Property to show whether it is visible or not, but I'm not sure how to make this dynamic. If I set to false then call the form with .ShowDialog() then try to change it later to True nothing actually changes in the form.
Am I missing something? Is there a way to dynamically change the visibility of a form object?
EDIT :: Adding the .Visible property change to the .add_click of the button.
$buttonYes.add_click({$progressbar1.visible = $True;Action $type;$confirm.Close()})
This does get the progress bar to appear, however the Marquee is not running which is strange, so it just shows an blank box...
EDIT 2 :: OK so looks like it does work, but only when run from the ISE. I've tried it on another system and running from command line or shortcut doesn't work. I've tried setting STA but still no go, the progress bar shows but now Marquee effect.
Related
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.
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!
Is there a property that tells if a form is deactivated by other form ShowModal procedure ?
EDIT :
My program has a tray icon that brings to front the main form when it's clicked. I want to disable this when another window is shown in modal state. Because not doing so the main form (which is disable) will cover the modal form and completly block my program.
This behaviour is to be expected. When a modal form is shown, the other forms are disabled. You don't need to disable anything at all, the framework already handles it all for you. The beep is sounding because you are attempting to interact with a disabled form.
If you want to be notified when your window has been disabled, for any reason, not just because a modal form has been shown, listen to the WM_ENABLE message. To test whether or not your main form has been disabled. Do that by calling the IsWindowEnabled Win32 function.
Having said that I feel that it is likely you've not diagnosed the issue correctly. It sounds like you might be suffering from window ownership problems, which are common in Delphi 6. Or perhaps you are attempting to restore the application incorrectly from your notification icon code. Use Application.BringToFront for that.
The VCL's handling of modal dialogs seem very mixed up. When you show a system provided modal dialog, e.g. MessageBox, windows are disabled whether or not they are visible. However, the VCL only disables visible windows when ShowModal is called. What's more, you cannot use Enabled to test whether or not the window is disabled, you must use the IsWindowEnabled Win32 function.
You can test Application.ModalLevel at any point in time to find out if there's a modal form. E.g.:
if Application.ModalLevel = 0 then
MainForm.Visible := True;
Note that non-TCustomForm descendants will not set modal level, API dialogs like a file open dialog or MessageBox for instance. If there's a possibility of such a thing, you might surround code that runs those dialogs with ModalStarted and ModalFinished.
It doesn't seem necessary in your case, but if you somehow need to be notified that a form/dialog is going modal, you can attach a handler to Application.OnModalBegin and Application.OnModalEnd events. You can use an TApplicationEvents component for that.
What is the proper way to use the SDK to make a dialog (which is not anchored to the add-on bar, etc. but shows centered on screen)? It doesn't seem like there is any API for this important capability. I do see windows/utils has open but I have two problems with that:
The dialog opening seems to require "chrome" privs to get it to be centered on the screen (and I'd be expectant of add-on reviewers complaining of chrome privs, and even if not, I'd like to try to stick to the SDK way).
While I can get the DOM window reference of the new window/utils' open() dialog, I'm not sure how to attach a content script so I can respond to user interaction in a way that prompts (and can respond to) privileged behavior ala postMessage or port.emit (without again, directly working with chrome privs).
Ok, this answer should have been pretty obvious for anyone with a little experience with the SDK. I realized I can just use a panel. In my defense, the name "panel" is not as clear as "dialog" in conjuring up this idea, and I am so used to using panels with widgets, that it hadn't occurred to me that I could use it independently!
Edit
Unfortunately, as per Bug 595040, these dialogs are not persistent, meaning if the panel loses focus, the "dialog" is gone... So panel looks like it is not a suitable candidate after all... :(
Edit 2
I've since moved on and have gotten things working mostly to my satisfaction with sdk/window/utils and openDialog on whose returned window I add a load listener and then call tabs.activeTab.on('ready', and then set tabs.activeTab.url to my add-on local HTML file so the ready event will get a tab to which I can attach a worker. There is still the problem with chrome privs I suppose, but at least the main communications are using SDK processes.
Update to Edit 2:
Code sample provided by request:
var data = require('sdk/self').data,
tabs = require('sdk/tabs');
var win = require('sdk/window/utils').openDialog({
// No "url" supplied here in this case as we add it below (in order to have a ready listener in place before load which can give us access to the tab worker)
// For more, see https://developer.mozilla.org/en-US/docs/Web/API/window.open#Position_and_size_features
features: Object.keys({
chrome: true, // Needed for centerscreen per docs
centerscreen: true, // Doesn't seem to be working for some reason (even though it does work when calling via XPCOM)
resizable: true,
scrollbars: true
}).join() + ',width=850,height=650',
name: "My window name"
// parent:
// args:
});
win.addEventListener('load', function () {
tabs.activeTab.on('ready', function (tab) {
var worker = tab.attach({
contentScriptFile: ....
// ...
});
// Use worker.port.on, worker.port.emit, etc...
});
tabs.activeTab.url = data.url('myHTMLFile.html');
});
if the panel loses focus, the "dialog" is gone...
It doesn't get destroyed, just hides, right? If so, depending on why it's getting hidden, you can just call show() on it again.
You'd want to make sure it's not being hidden for a good reason before calling show again. If there's a specific situation in which it's losing focus where you don't want it to, create a listener for that situation, then call if (!panel.isShown) panel.show();
For example, if it's losing focus because a user clicks outside the box, then that's probably the expected behaviour and nothing should be done. If it's losing focus when the browser/tab loses focus, just register a tab.on('activate', aboveFunction)
Simply adding ",screenX=0,screenY=0" (or any values, the zeroes seem to be meaningless) to the features screen seems to fix centerscreen.
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.