Im creating a simple powershell GUI using WPF like this one...
WPF GUI to powershell
The problem is that the textbox where i show logs is not being updated while the powershell script is executing some commands.
The same function that updates the text of the textbox also logs to standard output, but the messages are shown in the stdout immediately whereas the ones on the textbox are not shown until the end.
$MyTextbox.AddText($LogsLine) -> Not shown until the end
Write-Host ($LogsLine) -> Shown immediately
Is there any way to refresh the textbox after updating its "text" value?
Thanks!
I have tried looking for methods of the textbox or the form itself but i do not find a refresh function.
I have a Powershell V2 script that is done and all dandy. I pass parameters to it via
myscript.ps1 -firstparameter Donald -secondparameter Duck
I would like to have a "kicker" or "launcher" window/gui that simply lets me pass the arguments. I've designed the GUI in PrimalForms but I can't figure out how to send the arguments to my script and launch it.
My questions are:
How would I start my script with my parameters from my PrimalForms GUI (or any other gui)?
Am I even on the right track here (having my script as a separate scriptfile) or shold I try to put my entire script inside the PrimalForms project?
Is PrimalForms the way to go with a task like this? (I've been hearing about WPF and I'm thinking with the upcoming release of PS3 and all..)
PS: As of now I do not need any interaction with the GUI after "OK" have been pressed. I have no problem seeing a Powershell window pop up and do all the work in its "ugly glory"..
All help/tips are GREATLY appreciated:)
So in PrimalForms i'm imagining you create a few user input controls (textboxes, etc) and you have a button to click to launch your script with the parameters the user entered into your form input controls. If this is the case you would create an event handler for the button and add the code to call your script to the script block handler. If you are using the free community edition, on the right you will see at the top of the properties pane a lightning bolt icon. This will add the code templates linking scriptblocks to the various GUI events. Click on your button and find the OnClick event and double click in the text field to add the code template. When you copy the generated code you will see a script block created for your button. You can launch your script from there. You'll need to access the forms properties to get the data the user entered. Something like & .\MyScript -Param1 $form1.textbox1.text -Param2 $form1.textbox2.text.
We are working on a WPF application in .NET 4 that will be used with a touch screen. We are trying to use the built-in Windows OSK for our input, and the last remaining issue is to get the keyboard to open up as soon as a text box gets focus. Currently, if a text box gets focus, a small keyboard icon appears (this is the InputPanel icon) and the user has to tap that icon to make the keyboard open up.
Is there a way to skip the icon step, and just have the keyboard open up all the way on focus? Preferably something that can be set or coded in one place and apply to all text boxes globally? It also needs to use the current culture settings of the application thread (which it already appears to be doing).
I haven't been able to find anything in the control panel settings that lets you skip the icon step. I also found some examples online of using the TextInputPanel.CurrentInPlaceState, but when I implemented code to open up a TextInputPanel on preview focus of the main window, I kept getting COM INTEROP exceptions and basically hit a dead end (the Microsoft.Ink.dll is an interop DLL).
Is it possible that there is a registry key that can change the default CurrentInPlaceState to Expanded instead of HoverTarget? I haven't been able to find one in my net searching.
Thanks,
Valerie
EDIT: Here is some code that I put in the main window's code behind, as well as the exception message I keep getting - and I have no idea what it means or how to fix it (my net searches failed me!)
protected override void OnPreviewGotKeyboardFocus(KeyboardFocusChangedEventArgs e)
{
base.OnPreviewGotKeyboardFocus(e);
TextBox textbox = e.NewFocus as TextBox;
TextBox oldTextbox = e.OldFocus as TextBox;
if (oldTextbox != null && boxesToInputs.ContainsKey(oldTextbox))
{
TextInputPanel oldPanel = boxesToInputs[oldTextbox];
oldPanel.Dispose();
boxesToInputs.Remove(oldTextbox);
}
if (textbox != null)
{
// Make sure we've cleaned up old panels, just in case
if (boxesToInputs.ContainsKey(textbox))
{
boxesToInputs[textbox].Dispose();
boxesToInputs.Remove(textbox);
}
TextInputPanel newPanel = new TextInputPanel(((HwndSource)PresentationSource.FromDependencyObject(textbox)).Handle);
newPanel.DefaultInPlaceState = InPlaceState.Expanded;
newPanel.DefaultInputArea = PanelInputArea.Keyboard;
boxesToInputs[textbox] = newPanel;
}
}
And here is the exception message, which occurs when my code calls the TextInputPanel constructor:
Retrieving the COM class factory for component with CLSID {F9B189D7-228B-4F2B-8650-B97F59E02C8C} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
I verified that the platform target of the WPF app is x86. I ran Dependency Walker and it said that the Microsoft.Ink.dll I was using was 64 bit, and that two delay-loaded dependencies were missing (GPSVC.dll and IESHIMS.dll). I found a 32 bit version of Microsoft.Ink.dll, but I am still getting the same error, and Dependency Walker is saying the same thing - GPSVC.dll and IESHIMS.dll are missing.
I can't target x64, and I'd prefer not to have to put the missing DLLs into my application folder (if that would work?). I hope there is something simple I am missing, because this is a lot of trouble to just get rid of a keyboard hint...
Any help is greatly appreciated - I am a bit of a newb when it comes to working with unmanaged/interop assemblies...
I researched for a similar propose. In my case it was to create a custom OSK. It seems that (by now) it's not possible to create a custom input device. The explanation is in this link:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/a813a08a-7960-45fe-bc91-e81cdb75bd10
Moreover, I found a "workaround" which uses Win32 API calls to access SendKey method, and report input independently of the target. The project that I found is:
http://wosk.codeplex.com/
SendKey is also available on WinForms (see http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys.aspx ) but I'm not sure if it will produce the same behavior.
I'll checking these options in the following days, but perhaps some of this information might help.
Regards
Herber
I am working on a WinForm Application.
The Form has many fields/components but is poorly built.
for example a field is used as user name on one case and used as folder path on the other case. Code is quite poorly maintaned.
Is is possible that when i run the application and GUI appears, i can use a tool like 'spy++' which can show me 'names' of the components (not ids). For instance the name of a button or name of a label.
Or if i can use SPY++ for 'names' please tell me?
I would solve the problem by adding a ToolTip control to your form and iterating over each control and adding a Tool Tip message to each control that is the name of the control.
First, add a ToolTip object to your form (from the Tools section of the designer.) You can rename it, but for the sake of my demo, I left it as the default name toolTip1.
Next, add a method similar to the one I'm posting below to the code page of your form. (I'm assuming this is for C# but the code is simple and can easily be modified for VB or C++).
public void AddNameToToolTip(Control c)
{
toolTip1.SetToolTip(c, c.Name);
foreach (Control child in c.Controls) AddNameToToolTip(child);
}
Finally, from within the Form constructor, add the following line of code after the call to InitializeComponent().
AddNameToToolTip(this);
This will add a ToolTip message to each control in your form. All you should have to do is hover your mouse over each control and the ToolTip will pop up a message after a second or two displaying the name of the underlying control.
Alternatively, you can recursively adding a MouseHover event to each control and when the event is fired, write the name of the control to the debugger. This would also work if you are already using a ToolTip control within your form.
When our app is started programatically (either through custom action in MSI installer or when starting a new instance) in Windows Vista (also happens in Windows 7 Beta) it won't appear in the taskbar and isn't focused. Alt-tabbing to it will make it appear in the taskbar properly and stay there.
What causes this? I've seen this in some other apps before as well, but not sure why. Out app is .NET WinForms app. Never see this happen in XP, only Vista and 7
Edit: Well, it seems like the only time this happens reproducibly is when it's run by the installer, I believe there's other times it occurs, but I might just be crazy. The launching code is a bit complex to post because we handle various command line launch parameters and it launches a signin form before actually launching the main app etc.
Has anyone had to deal with this scenario before and worked it out?
Try checking your main application form "Form Border" property.
If it's ToolWindow (Fixed or Sizable), try changing it to FixedDialog for example.
This solved the problem in my case.
The usual reason for this is that your main application window doesn't have the window styles that let Windows know it's a main application window (rather than a tool window or a dialog box). So Windows is having to guess based on how the app was started, etc.
Use Spy++ to complare the window styles (especially extended styles) if your window to that of some other window that doesn't have this problem. Are you missing the WS_EX_APPWINDOW style? Are any other styles/extended styles different from other top level windows?
G.So's answer made me find the solution for my problem, wich was caused by the fact that i had my form sizable from launch, but set to borderless in the load void.
If anyone is interested in how i managed to keep the switch to borderless and have it pop up as it should in the taskbar without any dirty hacks.. here it is..
Make a new event from the form on the form's "Shown" event, and put your line of code for switching to borderless in here. Problem solved :)
private void Form1_Shown(object sender, EventArgs e)
{
this.FormBorderStyle = System.Windows.Forms.FormBorderStyle.None;
}
and for the lazy ones ;) >>>>
this.Shown += new EventHandler(Form1_Shown);
Thanks again G.So for clearing up what could cause this in the first place.
I stuggled with this issue as well, and found like a previous commenter said, you cannot have anything in the form's Load() event that changes that FormBorderStyle property. Move anything that changes it to the Shown() event.
Well, one solution is to use a hack like this. That's really not what it's for.
Usually the decision of whether a window will be in the taskbar or not is based on the border styles it uses. The article I linked to provides a bit more detail. The article's comment about the window having an owner or not is quite possible highly relevant to your issue, since the window might somehow be getting a different owner when launched by the installer.
That article is in VB but it's all based around API calls so the info it provides is pretty language independent.
Never see this happen in XP, only Vista and 7
Maybe it's a bug in Vista...?
What happens if you call SetForegroundWindow() (or equivalent in .Net)?
Edit
I did of course mean "BringWindowToTop()".
Or do both.
We had this same problem and fixed it by setting the form property showintaskbar property to true.
Weird that all windows os's dont run apps in the same way!
In our situation, this was tracked down to the form's text property being changed within the Load event.
After putting this inside a BeginInvoke, this odd behaviour no longer happened.
Hope this helps anyone else.
Example
private void Form_Load(object sender, EventArgs e)
{
...
...
...
// this needs to be inside a BeginInvoke otherwise it messes with the taskbar visibility
this.BeginInvoke(new Action(() =>
{
this.Text = "Something new";
}));
...
...
...
}
We encountered the same issue, also in Windows 8. Sometimes the form was receiving correctly the focus, but say just ~30% of the time.
We tried different solutions, but actually the one that worked was the following:
private void OnFormShown(object sender, EventArgs e)
{
// Tell Windows that the Form is a main application window
this.FormBorderStyle = System.Windows.Forms.FormBorderStyle.FixedDialog;
// Even if true, enforce the fact that we will the application on the taskbar
this.ShowInTaskbar = true;
// Put the window to the front and than back
this.BringToFront();
this.TopMost = true;
this.TopMost = false;
// 'Steal' the focus.
this.Activate();
}
Moreover, we ensure also not to set the title of the form during the Load event.