I have PowerShell script that creates a WPF form from inserted XML code. This form will run on a kiosk station and has no window (so no maximize, minimize, or close buttons) and consumes the entire screen.
Even though the form itself has no window buttons, a person can still press the WIN key on a keyboard, get the task bar, right click on the form in the task bar and choose to minimize, maximize, or close for the form.
So, I set an action for close to lock the workstation (which is better option for this kiosk instead of preventing the form from closing at all) by doing this:
$form.Add_Closing({
$shell = New-Object -ComObject "Wscript.Shell"
$shell.Run("%windir%\System32\rundll32.exe user32.dll,LockWorkStation")
})
I would also like to do this for Minimize if possible, but can’t seem to figure out how.
FYI. I’m not intending this to be a security feature per-se, but more so something that is better done then not for this kiosk station.
if $form is your form, then you could try this (wrapping the repetitive part in a function to stay DRY):
function Lock-Workstation {
$shell = New-Object -ComObject "Wscript.Shell"
$shell.Run("%windir%\System32\rundll32.exe user32.dll,LockWorkStation")
}
$form.Add_Closing({ Lock-Workstation })
$form.Add_StateChanged({
if($form.WindowState -eq "Minimized") {
Lock-Workstation
}
})
Since you don't want the window to be resized anyway, you could simply use:
$form.Add_StateChanged({ Lock-Workstation })
Related
I'm using powershell -new_console:as to open a new elevated powershell in a split view.
Unfortunately, my open console is hidden by that, and I need to hit the hotkey to unhide it again. Can I prevent this somehow?
My Quake-Style settings
Quake style slide down (checked)
Auto-hide on focus lose (checked)
Always on top (checked)
i am working on Silverlight 5,
Application has functionality like save data in user's local pc as CSV. while developing functionality it's working perfect at our local PC. when we click on "Export" Button save file dialog box appear and save at selected location. but after deployed on our server save file dialog box will not appear on screen.
dialog = new SaveFileDialog();
dialog.DefaultFileName = "Exported Data";
dialog.Filter = string.Format("File Type (*{0}) | *{0}", (".csv"));
dialog.DefaultExt = string.Format("{0}", ("csv"));
//Show the dialog
bool? dialogResult = dialog.ShowDialog();
Make sure you call ShowDialog() method right after "Export" button click event, this is Silverlight security feature.
See: http://msdn.microsoft.com/en-au/library/system.windows.controls.savefiledialog(v=vs.95).aspx
You show a save dialog control using the ShowDialog method. For security purposes Silverlight file and print dialogs must be user-initiated. This means you must show them from a user-initiated action such as the click event handler for a button. In addition, there is a limit on the time allowed between when the user initiates the dialog and when the dialog is shown. If the time limit between these actions is exceeded, an exception will occur.
In my Windows Form's Form_Load event, I want to show a FolderBrowserDialog to let the user select a directory, and if the directory they've selected is not valid (meaning it lacks certain files that the application needs), I want to show it again. However, when I create a new FolderBrowserDialog, it does not appear when I call ShowDialog.
while (ValidDirectorySelected() == false && tryAgain == true)
{
using (FolderBrowserDialog dialog = new FolderBrowserDialog())
{
dialog.ShowNewFolderButton = false;
if (dialog.ShowDialog() == System.Windows.Forms.DialogResult.Cancel)
{
tryAgain = false;
}
}
}
When I step into it, the dialog.ShowDialog() line is reached on the second time, and then nothing happens. The dialog does not appear, and the debugger doesn't move on. It just stops. It works perfectly the first time, but not the second. I've even tried just copying that entire using block and pasting it right after the first one, and the same thing happens. The dialog shows only once.
What do I need to do to show a FolderBrowserDialog more than once?
Solution:
Passing 'this' to ShowDialog fixed my issue. I also moved the using to outside of the while loop, to avoid needlessly re-creating the dialog.
Minimize Visual Studio, you'll find the dialog back.
This is a focus issue, triggered because you display the dialog in the Load event. When the dialog closes, there is no window left in your app that can receive the focus. Your Load event hasn't finished running so the app's main window isn't yet visible. Windows has to find a window to give the focus to and will select one from another program. Like Visual Studio.
When you display the dialog again, it cannot steal the focus back because Visual Studio has acquired it. So the dialog appears behind Visual Studio's main window, out of view.
You'll have to fix this by allowing your main window to become visible. And call dialog.ShowDialog(this) to be completely sure. You could use the Shown event, for example.
Try this:
using (FolderBrowserDialog dialog = new FolderBrowserDialog())
{
while (ValidDirectorySelected() == false && tryAgain == true)
{
dialog.ShowNewFolderButton = false;
if (dialog.ShowDialog() == System.Windows.Forms.DialogResult.Cancel)
{
tryAgain = false;
}
}
}
...move your using outside the while loop to keep from destroying the folder browser every time. You don't have to do that. You can reuse FolderBrowserDialog.
When I create a form (window) in PowerShell, I can usually display the form using .ShowDialog():
$form = New-Object System.Windows.Forms.Form
$form.ShowDialog()
.Visible is set to False before and after .ShowDialog().
But when I do a .Show() nothing is displayed on the screen:
$form.Show()
And .Visible is now set to True (presumably because .Show() made the form officially visible.)
When I now try to .ShowDialog() the form again, I get the following error message:
"Form that is already visible cannot be displayed as a modal dialog box. Set the form's visible property to false before calling showDialog."
But when I follow the instructions to .ShowDialog() again
$form.Visible=0
$form.ShowDialog()
the result is that nothing is displayed on the screen and PowerShell hangs and cannot recover (ctrl-c doesn't seem to work). I assume this is because the form is being displayed modally somewhere where I cannot see it (or tab to it). But why?
The coordinates of the form haven't changed. So how does the form decide when it is physically visible and when it isn't?
Avoid using Show() from PowerShell as it requires a message pump and that isn't something the PowerShell console provides on the thread that creates your form. ShowDialog() works because the OS does the message pumping during this modal call. Creating the form and calling ShowDialog() works reliably for me.
My problem: When using ShowDialog() as part of a powershell logon script, the first form window would not show and powershell would seem to freeze up on logon. Symptoms were simular to the original post.
Solution I found: Instead of using $form.showDialog(), use:
[System.Windows.Forms.Application]::Run($form)
Works great for me now, and only the first form in the series needed the change. All my other forms that come up afterwards in the script still use showDialog.
I've got a "Main Window" containing quite a few things, including, in the status bar (at the very bottom of the window), a "Support" button, which the user can use at any time to open a window containing our support phone number, along with a little chat functionality if the user prefers to chat with us.
The problem is that if the program is displaying a modal dialog, the "support" button is not clickable anymore.
Stopping using modal dialogs is not an option ; I use them because I sometimes want to force the user into performing a specific task before I can do something else in the software.
What's the best way to let the user contact the support without having to close the current modal dialog?
Modal dialogs should behave as modal dialogs, the user won't expect to be able to click a button in the main window even if it were possible.
Your best bet is to put a support button on the dialog too.
Using a shortcut key instead of a button may be an option. The functionality could be factorized into a base form class like this :
public class BaseForm : Form
{
protected override bool ProcessDialogKey(Keys keyData)
{
if (keyData == Keys.F1)
{
SupportForm f = new SupportForm ();
f.Show();
}
return base.ProcessDialogKey(keyData);
}
}
Not using modal dialogs is an option. You can disable other parts of your interface during the required interaction to get whatever it is that you need out of the user.
The solution is to avoid situations where the user 'must' do something. Modal dialogs often get in the way if, for example, the user wants to quit the application right at that moment, or see something in a backgrounded window, or refer to another part of your application. Instead of using them, design your interaction so that if there is a required action/piece of information, it's folded into the application logic.
Think about website design -- modal dialogs are very rarely found on the web, and for good reason -- they disrupt the user's workflow unnecessarily. And yet plenty of sites have 'required' information.
Don't use modal dialogs; they are a shortcut to avoid a better design.