I want to do something after the document have completely load... I dont want to use WebBrowser.DocumentCompleted Event, so please don't suggest me this.
I tried 2 ways to do it but they not work. Can someone tell me what I doing wrong?
Example 1
wb.Navigate("http://www.google.com");
while(wb.ReadyState != WebBrowserReadyState.Complete) { }
richtextdocument.Text = wb.DocumentText;
Example 2
wb.Navigate("http://www.google.com");
while(wb.isBusy == true) { }
richtextdocument.Text = wb.DocumentText;
Try to use timer to validate document load state.
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void timer1_Tick(object sender, EventArgs e)
{
if(webBrowser1.ReadyState == WebBrowserReadyState.Complete)
{
timer1.Enabled = false;
richTextBox1.Text = webBrowser1.DocumentText;
}
}
private void button1_Click(object sender, EventArgs e)
{
timer1.Enabled = true;
webBrowser1.Navigate("http://www.google.com");
}
}
What you are dealing with here is trying to call an inherently asynchronous method synchronously.
As you mentioned in the comments to your question that the reason for not using DocumentCompleted is that you will need to use that event for other purposes, what I suggest you do is to use the DocumentCompleted event, coupled with a private class boolean flag to determine if this is the special case of DocumentCompleted or not.
private bool wbNeedsSpecialAction; //when you need to call the special case of Navigate() set this flag to true
public Form1()
{
InitializeComponent();
wb.DocumentCompleted += new WebBrowserDocumentCompletedEventHandler(wb_DocumentCompleted);
}
void wb_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
{
if (wbNeedsSpecialAction)
{
richtextdocument.Text = wb.DocumentText;
wbNeedsSpecialAction = false;
}
else
{
//other cases of using DocumentCompleted...
}
}
public void Browse()
{
wbNeedsSpecialAction = true; //make sure the event is treated differently
wb.Navigate("http://www.google.com");
}
This will still allow you to control other cases within the event handler.
You must take special care to ensure that your user is not able to trigger another call to Navigate() before this 'special action' page finishes loading, otherwise it may steal the special case event. One way could be to block the UI until the page finishes loading, e.g.:
Cursor.Current = Cursors.WaitCursor;
while(wb.ReadyState != WebBrowserReadyState.Complete) {application.doevents }
Related
I want to check if the Clipboard consists of a data and if not, let the "Paste" Button be enabled. But unfortunately, even after I clear the Clipboard it still doesn't show it's null. I am working with Windows Forms.
I manually clear the clipboard:
private void button2_Click(object sender, EventArgs e)
{
Clipboard.Clear();
}
and then I add the following code to the Form LoadEvent:
if (Clipboard.GetDataObject() != null)
{
this.pn1_BtnPaste.Enabled = true;
}
And it makes a button enabled which is weird to me. Can anybody explain why is that happening?
EDIT:
Because I got understood wrong, let me change the code to make it more clear:
private void button2_Click(object sender, EventArgs e)
{
Clipboard.Clear();
if (Clipboard.GetDataObject() != null)
{
this.pn1_BtnPaste.Enabled = true;
}
else
this.pn1_BtnPaste.Enabled = false;
}
I click the "button2" and the "pn1_BtnPaste" is enabled anyway.
Data can appear on the clipboard at any time. The Application.Idle event is a decent way to update the button state:
public Form1() {
InitializeComponent();
Application.Idle += Application_Idle;
}
You have to unsubscribe it again when the window closes to be on the safe side:
protected override void OnFormClosed(FormClosedEventArgs e) {
Application.Idle -= Application_Idle;
base.OnFormClosed(e);
}
Clipboard.GetDataObject() does not work the way you think it does, it never returns null. If you want to handle any data then you can write the event handler like this:
private void Application_Idle(object sender, EventArgs e) {
PasteButton.Enabled = Clipboard.GetDataObject().GetFormats().Length > 0;
}
But it is pretty likely you'll find out that handling every possible format is lot let practical than you assumed.
I have a question regarding looping with button click event, I've tried many methods & searched many pages in search for a simple answer for the past hour, but the truth is each answer just looks like alien code, probably because I'm still very new to developing.
Here's a simplified version of what I'm trying to do :
private string Message = "Hello";
private void Spam(bool loop)
{
if (loop == true)
{
while (loop == true)
{
MessageBox.Show(Message);
}
}
else { MessageBox.Show("Spamming has stopped !! "); }
}
private void button1_Click(object sender, EventArgs e)
{
Spam(true);
}
private void button2_Click(object sender, EventArgs e)
{
Spam(false);
}
Obviously this isn't my API, or it'd be a useless thing to invent, however, the code itself is long & you guys always ask for "relevant code" (No disrespect), so there it is.
My problem : Breaking out of the spam loop upon clicking button 2, the code to me looks decent enough for the API to figure out, but each time button 1 is clicked, the API freezes.
Use a background worker to do your work. You can use the cancellation feature to break out of it when you're done. Your loop as you have it will block the UI thread when executed syncronously, which is why your GUI becomes unresponsive. Note if you do any interaction with the UI in the do work delegate, you need to marshal back onto the UI thread (via invoke for example).
private BackgroundWorker _worker = null;
private void goButton_Click(object sender, EventArgs e)
{
_worker = new BackgroundWorker();
_worker.WorkerSupportsCancellation = true;
_worker.DoWork += new DoWorkEventHandler((state, args) =>
{
do
{
if (_worker.CancellationPending)
break;
Console.WriteLine("Hello, world");
} while (true);
});
_worker.RunWorkerAsync();
goButton.Enabled = false;
stopButton.Enabled = true;
}
private void stopButton_Click(object sender, EventArgs e)
{
stopButton.Enabled = false;
goButton.Enabled = true;
_worker.CancelAsync();
}
Update 2019:
BackgroundWorker is now largely obsolete, replaced by the async/await feature in later versions of C# which is easier to use. Here is an example of how to achieve the same thing using that feature:
private CancellationTokenSource _canceller;
private async void goButton_Click(object sender, EventArgs e)
{
goButton.Enabled = false;
stopButton.Enabled = true;
_canceller = new CancellationTokenSource();
await Task.Run(() =>
{
do
{
Console.WriteLine("Hello, world");
if (_canceller.Token.IsCancellationRequested)
break;
} while (true);
});
_canceller.Dispose();
goButton.Enabled = true;
stopButton.Enabled = false;
}
private void stopButton_Click(object sender, EventArgs e)
{
_canceller.Cancel();
}
There's one important thing to remember:
While your code is being executed, the user cannot interact with your user interface.
That means: You first need to exit the loop (i.e. return from the Spam method), and then the user can click Button2.
That's a hard truth, because it means you cannot write the code in the way you wanted to. Fortunately, there are a few ways to work around that:
Don't use a loop. Use some kind of timer to do the "spamming". Button1 starts the timer, Button2 stops it. What kind of timer is available depends on the user interface library you use (WinForms has a Timer, WPF has a DispatcherTimer).
Do the "spamming" in a background thread. This will allow your user interface to stay responsive, and you can communicate with the background thread, for example, by setting a volatile Boolean. This, however, is an advanced topic (and can quickly lead to complex synchronization issues), so I suggest that you try the other option first.
When you click button1 the Spam method is called and loop is starting. When you click button2 Spam method is called but it's not the same. It's the second execution, so it will check the condition and won't enter into the loop, but the loop in the first call sill will be running.
You should use a flag and the loop should use that flag to determine whether it should be still running. It should look something like that:
bool run = false;
string message = "This API is not original";
private void Spam()
{
while (run == true)
{
MessageBox.Show(message);
}
}
}
private void button1_Click(object sender, EventArgs e)
{
message = "Hellooo";
flag = true;
Spam();
}
private void button2_Click(object sender, EventArgs e)
{
flag = false;
}
Take a look at this concept:
private bool loop = false;
private void Start()
{
loop = true;
Spam("Some Message??");
}
private void Spam(string message)
{
while (loop)
{
MessageBox.Show("This API is not original");
}
}
private void button1_Click(object sender, EventArgs e)
{
loop = true;
}
private void button2_Click(object sender, EventArgs e)
{
loop = false;
}
However, the user won't be able to press a button if a MessageBox keeps popping up as it takes up the main UI thread. In order to prevent this you could use BackgroundWorker or start a new thread.
I am new to c# and kind of winging it. using Microsoft Visual C# 2010
I have checked many similar posts and none of the suggestions seem to help
I am getting the following error: "Cannot access a disposed object"
which references the main form here
private void btn_RunPkgs_Click(object sender, EventArgs e)
{
RunPackages rp = new RunPackages();
this.Hide();
rp.ShowDialog();//The error points to this line
this.Show();
}
here is the code that blows up when the security check fails.
private void securityCheck()
{
if (MyGlobals.FormCheck("RUN_JOBS") == 1)
{
InitializeComponent();
}
else
{
//this.BeginInvoke(new MethodInvoker(this.Close));
//this.DialogResult = System.Windows.Forms.DialogResult.Cancel;
MessageBox.Show("You do not have permission to access this form!");
//this.Close();
this.Dispose();
}
}
EDIT
It looks like I am going to go with Adriano Repetti's idea of putting the security where I call the page, but I am a little nervous now having any security on the page.
private void btn_RunPkgs_Click(object sender, EventArgs e)
{
if (MyGlobals.FormCheck("RUN_JOBS") == 1)
{
RunPackages rp = new RunPackages();
this.Hide();
rp.ShowDialog();
this.Show();
}
else
{
MessageBox.Show("Not for You!");
}
}
private void btn_ListUpdater_Click(object sender, EventArgs e)
{
if (MyGlobals.FormCheck("MDM") == 1)
{
ListUpdater lu = new ListUpdater();
this.Hide();
lu.ShowDialog();
this.Show();
}
else
{
MessageBox.Show("Private!");
}
}
EDIT2
Came up with the following possible solution but am nervous to use it because I am new at this and don't know what issues there might be. Any problems with just creating an event handler for form load?
namespace RunPackages
{
public partial class ListUpdater : Form
{
public ListUpdater()
{
InitializeComponent();
this.Load += new EventHandler(securityCheck);
}
private void securityCheck(object sender, EventArgs e)
{
if (MyGlobals.FormCheck("MDM1") == 0)
{
MessageBox.Show("Not Allowed!");
this.Close();
}
}
You can't dispose of the form within the form itself. The ShowDialog() method tries to access the form on exit for things such as DialogResult.
After a form has been disposed almost all of its methods can't be accessed (and most of its properties are invalid).
In your first line of btn_RunPkgs_Click() you create an object and you dispose it inside its constructor. Per se, even if pretty bad habit you may even call Dispose() from within constructor, it may even work but then you try to use such object ShowDialog() will generate ObjectDisposedException. Note that this code will also lead to same result (an exception):
RunPackages rp = new RunPackages();
rp.Dispose();
Yes you may check IsDisposed but that won't make code readable and problem (IMO) is you're mixing things. Constructor shouldn't contain such logic.
The point isn't just where you dispose your form. What's better is to don't even create such form (let me assume, because you call InitializeComponent(), that securityCheck() is called inside form constructor), for this you may use a factory static method:
public static bool TryShowDialog(Form currentForm)
{
if (MyGlobals.FormCheck("RUN_JOBS") != 1)
return false;
if (currentForm != null)
currentForm.Hide();
RunPackages dlg = new RunPackages();
dlg.ShowDialog();
if (currentForm != null)
currentForm.Show();
return true;
}
Your calling function will then be reduced to:
private void btn_RunPkgs_Click(object sender, EventArgs e)
{
RunPackages.TryShowDialog(this);
}
Note that such function is highly eligible for some refactoring (for example to extract code to hide/show existing form). Something like this:
public static bool ShowDialog<T>(Form currentForm, string authorizationId)
where T : Form, new()
{
if (MyGlobals.FormCheck(authorizationId) != 1)
return false;
if (currentForm != null)
currentForm.Hide();
T dlg = new T();
T.ShowDialog();
if (currentForm != null)
currentForm.Show();
return true;
}
Used like this (now code is reused everywhere):
SecurityHelpers.ShowDialog<RunPackages>(this, "RUN_JOBS");
Please note that calling code may be simplified (authorizationId may be an attribute on RunPackages, for example, and also currentForm can be deduced from current active form).
EDIT Calling Close() isn't better, if window handle has not been created (let's simplify little bit: it's created when window is shown) internally it'll call Dispose() (then above applies).
I would not try to disrupt the chaining of events that lead to the form creation.
The side effects are difficult to predict and what works today could not work in future versions.
Instead I would try a different approach
private void securityCheck()
{
if (MyGlobals.FormCheck("RUN_JOBS") == 1)
{
InitializeComponent();
}
else
{
Label message = new Label();
message.Dock = DockStile.Fill;
message.Text("You do not have permission to access this form!.");
message.TextAlign = ContentAlignment.MiddleCenter;
this.Controls.Add(message);
}
}
In this way I let the form show with just one label that covers the entire form surface with your message. The user could only close the form (provided that you have not removed the Control Box)
By the way, this has the advantage of avoiding dangerous oversights because it doesn't require any change on the calling code and the final effect is to effectively block the use of the form.
If you insist in closing the form during its constructor phase then you could get some advices from this question
I came up with the following, can anyone tell me if there are any issues with this?
namespace RunPackages
{
public partial class ListUpdater : Form
{
public ListUpdater()
{
InitializeComponent();
this.Load += new EventHandler(securityCheck);
}
private void securityCheck(object sender, EventArgs e)
{
if (MyGlobals.FormCheck("MDM1") == 0)
{
MessageBox.Show("Not allowed!");
this.Close();
}
}
etc...
Use a flag. For example change the code, like this:
public bool IsDisposed;
private void securityCheck()
{
if (MyGlobals.FormCheck("RUN_JOBS") == 1)
{
InitializeComponent();
}
else
{
//this.BeginInvoke(new MethodInvoker(this.Close));
//this.DialogResult = System.Windows.Forms.DialogResult.Cancel;
MessageBox.Show("You do not have permission to access this form!");
//this.Close();
this.Dispose();
this.IsDisposed = true;
}
}
Then:
private void btn_RunPkgs_Click(object sender, EventArgs e)
{
RunPackages rp = new RunPackages();
if(rp.IsDisposed)
return;
this.Hide();
rp.ShowDialog();//The error points to this line
this.Show();
}
I am using a background worker to analyze serial port data on a pop-up Windows form in my application. As part of error-proofing my application I want to be able to stop/cancel the test script if the user tries to close the form during operation. Currently I have my backgroundworker setup as follows:
private void backgroundworker_DoWork(object sender, DoWorkEventArgs e)
{
LogMsg(LogMsgType.Normal, "Test Started");
// execute test script
}
If I try to close the form I get a "Invoke or BeginInvoke cannot be called on a control until the window handle has been created" exception at my LogMsg() portion of code:
public void LogMsg(LogMsgType msgtype, string msgIn)
{
rtbAssignSATest.Invoke(new EventHandler(delegate
{
rtbAssignSATest.SelectedText = string.Empty;
rtbAssignSATest.SelectionFont = new Font(rtb.SelectionFont, FontStyle.Bold);
rtbAssignSATest.SelectionColor = _mainForm.LogMsgTypeColor[(int)msgtype];
rtbAssignSATest.AppendText(msgIn);
rtbAssignSATest.ScrollToCaret();
}));
}
With this in mind I evaluated other posts on StackOverflow on how to cancel a thread when closing a windows form. In doing so I came across a portion of code that I have incorporated into my application (see below).
volatile bool mClosePending = false;
volatile bool mCompleted = false;
private void backgroundWorker1_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
mCompleted = true;
if (mClosePending)
{
this.Close();
}
}
protected override void OnFormClosing(FormClosingEventArgs e)
{
if (!mCompleted)
{
backgroundWorker1.CancelAsync();
this.Enabled = false;
e.Cancel = true;
mClosePending = true;
return;
}
base.OnFormClosing(e);
}
Even after incorporating this code I am still seeing the error at the LogMsg() portion of code. Any help would be appreciated.
Let the base.OnFormClosing(e) to execute even after you set the e.Cancel = true. I think this will work.
protected override void OnFormClosing(FormClosingEventArgs e)
{
e.Cancel = !mCompleted;
base.OnFormClosing(e)
if (!mCompleted)
{
backgroundWorker1.CancelAsync();
this.Enabled = false;
mClosePending = true;
}
}
Could you put your
base.OnFormClosing(e);
line at the top of the method? Just in case it is overwriting your
e.Cancel = true;
Edit, also, instead of using volatile, why don't you use
lock (this) {}
When do you start the background worker? It could be before the controls on the Form have been loaded - this would explain the error message...
I'd like to use a BackgroundWorker for background operations because I thought there is no need to take care of "BeginInvoke" etc. when updating WinForm-Controls. Is that right? As far as I know, you can update WinForms controls directly by using the ProgressChanged and RunWorkerCompleted eventhandlers.
But I can't, I although get the following exception:
Control control name accessed from a thread other than the thread it was created on
Some code:
public partial class ConfigurationForm : Form
{
public ConfigurationForm()
{
InitializeComponent();
backgroundWorker1.WorkerReportsProgress = true;
backgroundWorker1.WorkerSupportsCancellation = true;
label1.Text = String.Empty;
// [...]
}
private void StartButton_Click(object sender, EventArgs e)
{
if (backgroundWorker1.IsBusy != true)
{
label1.Text = "Converting...";
backgroundWorker1.RunWorkerAsync();
}
}
private void CancelButton_Click(object sender, EventArgs e)
{
if (backgroundWorker1.WorkerSupportsCancellation == true)
{
backgroundWorker1.CancelAsync();
}
progressBar1.Dispose();
this.Close();
}
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
progressBar1.Value = e.ProgressPercentage;
// EXCEPTION here, why?
}
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
BackgroundWorker worker = sender as BackgroundWorker;
Converter c = new Converter();
c.Start(worker, e);
}
private void backgroundWorker1_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
// EXCEPTION in all cases, why?
if (e.Cancelled == true)
{
label1.Text = "Canceled";
}
else if (e.Error != null)
{
label1.Text = "Error: " + e.Error.Message;
}
else
{
label1.Text = "Done!";
}
}
}
I have to say, this is not a WinForms application but an VSTO PowerPoint add-in. The Form above gets created by the add-in like this when the user is clicking an icon in the ribbon bar of PowerPoint:
//Do I need [STAThread] here? but doesn't seem to work anyway
private void button1_Click(object sender, RibbonControlEventArgs e)
{
ConfigurationForm config = new ConfigurationForm();
config.Show();
}
Can you tell me what's the problem here?
I posted the link but I don't actually think it is the best solution. Clearly the failure occurs because you never called Application.Run() or used Form.ShowDialog(). You can assign the context explicitly as shown but you can get some very tricky problems if you don't do it right. Like assigning it more than once.
The better fix is to ask it to automatically install itself. Which then ensures that whatever form you create will then install it only when it wasn't done before. Put this in front of the form creation code:
WindowsFormsSynchronizationContext.AutoInstall = true;
With the big advantage that if the code ever gets repeated, you won't create another instance of it and potentially screw up the thread's ExecutionContext.
Do consider ShowDialog() as another fix. If I'm not mistaken then you now also have a problem with tabbing and shortcut keystrokes.
Your assumption would be correct for Windows Forms. The way it works though is BackgroundWorkers uses the SynchronizationContext of the current thread. In a windows app, that will be a WindowsFormsSynchronizationContext, which does the marshalling for you.
In a VSTO app, it won't be. It will probably just be the default one, which simply executes the methods. The link from Hans Passant has the code you need to get it to work as expected. I.e.:
System.Threading.SynchronizationContext.SetSynchronizationContext(new WindowsFormsSynchronizationContext());
...create and start your background worker here...