|
thanks I fiqure out with help form msdn
Learning to Code
|
|
|
|
|
Hi,
I made a Form derivated class and I'd like to put some code in the Load event so when I use it, it will get the application icon (if any) and show it in the top left corner (as any windows software). I saw I few methods but they assume I know the namespace and the icon name, but as I told you the form may be used in any application, so I have to find out those informations too...
Thanks,
Dirso
|
|
|
|
|
Dirso wrote: it will get the application icon (if any) and show it in the top left corner
An application can have many icons, which one do you want?
Dirso wrote: I saw I few methods but they assume I know the namespace and the icon name
Well, that's because you have to choose between the many potential icons that may exist in your application.
Dirso wrote: as I told you the form may be used in any application
Actually, you didn't. This is the first time you mentioned that piece of information.
|
|
|
|
|
Hi,
I want the main application icon. That one you choose in the application property window.
Thanks,
Dirso.
|
|
|
|
|
Try putting the following code in the constructor for your form. It should pick up the Icon for any app in which it is included.
<br />
this.Icon = Icon.ExtractAssociatedIcon(System.Reflection.Assembly.GetEntryAssembly().Location);<br />
Henry Minute
If you open a can of worms, any valid solution *MUST* involve a larger can!
|
|
|
|
|
It worked like a charm!!! Thank you so much!!!
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
