|
how do you open the file browser dailog Using "Open" button click
|
|
|
|
|
craigMUTOKOKAI wrote: how do you open the file browser dailog Using "Open" button click
The same way as you'd handle any button click event.
In your event handler code you need to create an OpenFileDialog, set it up as you want (or not, if you are happy with the default behaviour) and then call ShowDialog() on it.
The DialogResult will indicate whether the user Cancelled the dialog or not.
|
|
|
|
|
DialogResult DialogResult_Logout = MessageBox.Show("Do you want to logout and return to Page Login?", "Logout", MessageBoxButtons.YesNo, MessageBoxIcon.Question);
if (DialogResult_Logout == DialogResult.Yes)
{
UserControl_PageLogin_Visible(true);
}
Is this what you want? 
nelsonpaixao@yahoo.com.br
trying to help & get help
|
|
|
|
|
Hello all,
can any body tell me how to release resources hold by thread before aborting it?
Is there a way to check what resources a thread is holding?
Thanks
|
|
|
|
|
Member 2324483 wrote: can any body tell me how to release resources hold by thread
Could you be more specific? What resources? How is the thread "holding" them?
led mike
|
|
|
|
|
here is the scenario.
My application has different dash boards and each dash board has different parts, which are loaded asynchronously. I am using remoting to make calls to server and load dashboard parts. There are different threads being created to load different dashboard parts and calls go over remoting channel asynchornously. When another dashboard is selected on UI, i am disposing all parts in current context and aborting threads being created, which some times freezing the UI. I am trying to find what could be the reason for UI freeze.
Please suggest me good debugging tools as well.
|
|
|
|
|
Member 2324483 wrote: i am disposing all parts in current context and aborting threads being created, which some times freezing the UI. I am trying to find what could be the reason for UI freeze.
Not good, see Guffa's reply. Don't abort threads.
led mike
|
|
|
|
|
Unless the code in the threads are specifically written to support abortion, you should not abort them. Aborting a thread means that an exception is thrown in the thread, which can be anywhere in the code. If not every single line in the code is written with this in mind, it is very likely that the code will crash and leave resources hanging.
Create a way to tell the threads that they should finish. That way you can let them clean up the resources in a well behaved manner before exiting. You can for example use a synchronised variable in the thread class that you change from the main thread.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa, i removed abort code, my UI is working fine now. But, can you tell me from my scenario above, why UI is getting freezed? (FYI.. the other threads, which i have created are background threads).
|
|
|
|
|
It look like Guffa has left the building, so I'll have a go at this one 
The only difference that setting IsBackground makes is that the thread cannot keep the process alive when it is being shut down. It is a bit of a kludge at the best of times.
As Guffa and led mike have said, using Abort is bad practice. The truth is, you can't know what the thread is doing when the ThreadAbortException is thrown - it will very likely be executing somewhere in the Framework ( in your case probably in something to do with Remoting ). This code may hold internal locks or other resources that are left abandoned by the exception. Orphaned locks will lead to deadlocks when other threads call into the same code, which I suspect is why your UI is freezing.
Abort exists for the CLR to use when tearing down a process. It should never be called by user code.
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
thanks Nick, this is great information for me. Now the things are more clear. Is there any way to trace the "suspect" (in your reply)?
|
|
|
|
|
If you run your app under the debugger and break when it freezes, you can see the call stack of your UI thread. This might give you an idea.
The point is that you should implement some deterministic functionality to stop unwanted threads cleanly, and not use Abort. Then the problem will just go away.
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
Thats right, i removed Abort everything working fine. Just for knowledge, trying to debug what bad happening when Abort is used. And want to make sure that the thread i was Aborting (now not) is not hanging out somewhere in app domain consuming any memory.
|
|
|
|
|
Member 2324483 wrote: Just for knowledge, trying to debug what bad happening when Abort is used.
Using Abort will throw the exception at different places each time - this is the problem with it. So I don't think you will learn anything useful from debugging it!
Member 2324483 wrote: And want to make sure that the thread i was Aborting (now not) is not hanging out somewhere in app domain consuming any memory.
You can use the debugger for this. Give your threads a name, break the debugger after they should have terminated, and then look at the "Threads" window in VS to see if they are actually gone.
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
Thanks everyone, who made me understand the problem.
|
|
|
|
|
You're welcome
----------------------------------
Be excellent to each other
|
|
|
|
|
Nick Butler wrote: Abort exists for the CLR to use when tearing down a process. It should never be called by user code.
AFAIK, calling abort from the same thread is safe. It won't throw ThreadAbortException.
|
|
|
|
|
Calling Abort on your own thread is the only ( barely ) acceptable use. It does throw a ThreadAbortException, but you know exactly what your thread is doing when it is thrown: it's in Thread.Abort!
This should still be avoided, though. There are better ways to terminate a thread.
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
Nick, few brief better ways to terminate a thread?
|
|
|
|
|
Member 2324483 wrote: few brief better ways to terminate a thread?
Better way is what Guffa said. Let the thread check a boolean value and if it is set as false, exit from the thread method. Something like
volatile bool canContinue = true;
void ThreadMethod(){
while(canContinue){
}
}
void StopThread(){
canContinue = false;
}
|
|
|
|
|
Hi,
Please advice me how to implement Active Document Container applications in C#. Is that possible to interact with Active Document Application developed in VC++ 6.0 or a brand new concept or technology available with C# ?
Please advice ...
|
|
|
|
|
Does anybody knows how can i beautifully copy data from doc1 to doc2.
IHTMLDocument2 doc1 = null;
IHTMLDocument2 doc2 = null;
private void webBrowser1_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
{
doc1 = webBrowser1.Document.DomDocument as mshtml.IHTMLDocument2;
doc2=doc1;--->this create reference. I don't want like that
}
Thanks for your help
|
|
|
|
|
|
Antonio David Gonzalez wrote: This article explains several ways to clone objects in C#:
netJP12L wrote: IHTMLDocument2
Antonio, IHTMLDocument2 is a COM Interface, not a managed object.
led mike
|
|
|
|
|
So what do you guys think how should i copy the data. The problem is that I want to see if doc1 objects has been changed or not by comparing the initial state of the doc1 and storing in doc2.
i.e
if(doc1.body.innerhtml!=doc2.body.innerhtml)
{
MessageBoxshow("doc1 object has been changed");
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
