|
IIRC this is how it works:
- the assembly name is set in the project's properties; it determines the DLL/EXE name for future builds.
- the default namespace name is set in the project's properties, it is used when NEW source files are created.
- when you want to change a namespace, you have to do it manually, and in every relevant source file. Warning: there may be files you're unaware of, such as the Designer-generated files and the top-level file (Program.vb/cs).
- what gets to run inside VS is the Main method of the class that is named as "startup object" in the project's properties; the default is Program.Main().
So change whatever you want and make/keep it consistent.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: So change whatever you want and make/keep it consistent.
Hm... it's only a single form. Rather than go thru all that, I'll create a new project with a name I like (instead of "TableStuff"  ) and import the form from the other project.
Thanks once again!
Everybody SHUT UP until I finish my coffee...
|
|
|
|
|
Is it possible to tell when a WinForm app is being closed from Visual Studio when a developer uses the "Stop Debugging" button? I'd like to perform some file cleanup, etc whenever the app shuts down, but when the app is closed from VS itself vs. the close button the form, the closing, dispose, etc is not called.
Just wondering if someone has run into this and what they may have done. Thanks for any suggestions or comments.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
|
|
|
|
|
Form_Closing event is definitely called buddy...Check again..
|
|
|
|
|
Closing is not called. When stopping the app with the "Stop Debugging" button in Visual Studio (take your flavor, 2005 or 2010) instead of closing the app through the form, the dispose, finalize and Form_closing events are bypassed. You can verify this by putting breakpoints on each and seeing if your app stops there.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
|
|
|
|
|
Let me verify it, I will get back to you..
|
|
|
|
|
All closing and exiting events will equally fire inside or outside Visual Studio. Use one of them and take advantage of this[^].
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Hey Luc,
I'm familiar with the Debugger.IsAttached because I have some debug.print statements that occur during various routines. I'm feeling rather blonde today.
I created a new WinForm app from scratch in VS2010.
Stuck this code in
Private Sub Form1_FormClosing(sender As Object, e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
MessageBox.Show("Look ma, I'm closing")
End Sub
If I start the app and close it with the X in the caption bar, woot!
If I start the app and close it with the Stop Debugging button in VS on the debugging toolbar, it's just not called? Am I totally overlooking something?
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
|
|
|
|
|
Nope. When you click on Stop Debugging, your code stops, period. There is no further exectuion of your application code. So, no, there is no way to do your file cleanup from inside your application. This would have to be done seperately, from some batch of script operation you launch yourself.
|
|
|
|
|
|
Thanks for the answers, just wanted to make sure I wasn't overlooking something. It would be nice to have a post debug (like the pre/post build events) events, but how often would you really use them. Really hate to rely on devs. having to run a bat file or something else, because it's only human to error, but that's the only real option here.
Thanks again.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
|
|
|
|
|
I assume you are trying to get back to a start up state, is it possible to move the cleanup to the aplication start process?
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I have that being done already (load and form_closing), but I wanted to cover the scenario in which a developer stopped the app via stop debugging button and immediately shuts VS after that. No biggie, I'll just make it known. Kinda a special case scenario.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
|
|
|
|
|
I see no solution, stopping the debug session aborts the process, without generating any of the usual events (Form.FormClosing, Application.ApplicationExit, etc).
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Your question is clear & Dave is correct.
|
|
|
|
|
VB makes a distinction between End and Stop, two keyworks inherited from proto-BASIC. End closes things down, fires events and cleans up memory; Stop does exactly that: stops execution and leaves the application in a suspended state that can be inspected.
I believe that "Stop Debugging" is effectively the same as the Stop statement, which means that execution just... stops. If you need to test clean up code while debugging your application, you should close the application in the same way your users will close it, such as the "Close Form" button on the main form, clicking a different button, using a menu item or the like.
|
|
|
|
|
This is my first time building a background thread. It's working but I would really appreciate an opinion or two as to whether I'm doing it the right way. I'll keep it brief as possible:
The app includes a TreeView and ListView, and when a TreeNode is clicked the ListView displays image files from the corresponding directory. I wanted the thumbnail images in the ListView to retain their aspect ratio so I'm drawing a scaled image inside an empty 64x64 thumbnail. If a dir has a lot of large files this can be quite slow.
So, I wrote a sub that gets images for the ListView via ExtractAssociatedIcon to populate the ImageList in the short term, then afterward creates a background thread (MakeThms) to replace the icons in the ListView's ImageList with thumbnails from the original images. The first sub gets the file names and adds the ListViewItems with system icons for the images:
Private Sub PopulateListView()
Try
If MakeThms.IsAlive Then
MakeThms.Abort()
End If
Catch ex As Exception
End Try
Try
MakeThms = New Thread(AddressOf BuildThumbnails)
MakeThms.Start()
Catch ex As Exception
MsgBox(ex.ToString, MsgBoxStyle.Exclamation, title)
End Try
End Sub
Private Sub BuildThumbnails()
For z As Integer = 0 To images.Count - 1
imgList.Images(z) = thm
Next z
lvFiles.Invalidate()
End Sub
I've been testing it for an hour or so and so far no problems. But I'd appreciate any advice if someone sees a potential problem with how I'm getting it done.
Everybody SHUT UP until I finish my coffee...
|
|
|
|
|
I rarely touch VB so I might be wrong, but;
if the BuildThumbnails function fails to convert the first thumbnail, you won't have any thumbnails at all.
(This does not get caught by the try-catch block at MakeThms.Start())
A try-catch block in the BuildThumbnails function would be nice, that way you'll at least have the scaleable thumbnails.
|
|
|
|
|
nbgangsta wrote: ...if the BuildThumbnails function fails to convert the first thumbnail, you won't have any thumbnails at all.
(This does not get caught by the try-catch block at MakeThms.Start())
True, I need to add a Try Catch block there. I'm looking at it again this morning and thinking maybe I should use a BackGroundWorker instead of creating my own threads. Sometimes the info at MSDN just bounces off my head instead of soaking in.
Everybody SHUT UP until I finish my coffee...
|
|
|
|
|
I have a number of comments:
1.
I don't like Thread.Abort() as it may leave things in an unknown state. I prefer a cooperative way of terminating a thread, which implies the thread code itself checks an exit condition regularly (requiring some code, and causing some exit delay).
Note: when cooperative, you don't need a new thread each time, it could simply switch to the new job when leaving the old one.
2.
I detest empty catch blocks, I do appreciate you had a comment in there.
If all it does is cope with MakeThms possibly being Nothing, then better test for that explicitly.
3.
lvFiles.Invalidate() is forbidden in anything but the main thread. Don't tell me you are either running a very old .NET version (1.x) or have set lvFiles.CheckForIllegalCrossThreadCalls false? For your penitence read this[^].
4.
when using real Thread instances you should consider setting IsBackground true; if not such running thread could prevent your app from exiting when the main form gets closed.
5.
This situation would be better served by a BackgroundWorker which solves 3 and 4 for you, as it borrows a Thread from the ThreadPool, runs it in the background, and terminates by executing its RunWorkerCompleted handler on the main thread.
6.
when multi-threading, things could go terribly wrong when shared data isn't properly synchronized. I can't tell in your case, just assume the main thread sets imgList or imgList.Images to Nothing while your extra thread is running.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: 1.
I don't like Thread.Abort() as it may leave things in an unknown state. I prefer a cooperative way of terminating a thread, which implies the thread code itself checks an exit condition regularly (requiring some code, and causing some exit delay).
I wasn't sure exactly how to terminate the thread, and wasn't sure if I needed to explicitly end it in this case because it just ran through the "z" loop once and exited the sub. In a case like this, is the thread still alive once the sub has finished?
Luc Pattyn wrote: 2.
I detest empty catch blocks, I do appreciate you had a comment in there.
If all it does is cope with MakeThms possibly being Nothing, then better test for that explicitly.
I should have explained myself better in the comments. I don't usually leave empty catch blocks. I'm still studying in this area. If I do something like If MakeThms.Equals(Nothing) Then I get a null reference exception.
Luc Pattyn wrote: 3.
lvFiles.Invalidate() is forbidden in anything but the main thread. Don't tell me you are either running a very old .NET version (1.x) or have set lvFiles.CheckForIllegalCrossThreadCalls false? For your penitence read this[^].
I'm running .Net 3.5 / VS 2008 Express. I haven't set lvFiles.CheckForIllegalCrossThreadCalls to false. I do get an exception if I use lvFiles.Refresh(). I was pretty sure I shouldn't do this, but amazingly it worked. My primary test directory has 90 images, each 1900x1080 and about 800KB. It takes about 3 seconds to completely rewrite the ImageList. If I quickly select another directory in the TreeView before it's done, it appears to work without any problems. But I was curious since I was touching another thread. I'll dig into the linked article after posting here. Thanks!
Everybody SHUT UP until I finish my coffee...
|
|
|
|
|
1. A thread that runs out of code just terminates; pretty similar to a method that reaches its end and returns.
2. of course If MakeThms.Equals(Nothing) Then is no good, when MakeThms is Nothing, you can't dereference it, so whatever is following the period will cause a bomb. Just do If MakeThms = Nothing Then.
3. Well I am surprised. If that is allowed, then I'll find some use for it indeed. I'll investigate.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Luc Pattyn wrote: 1. A thread that runs out of code just terminates; pretty similar to a method that reaches its end and returns.
I was thinking that was the case. Thanks for confirming it. As I told nbgangsta, sometimes the info at MSDN just bounces off my head instead of soaking in. That's when I end up in the CP forums.
Luc Pattyn wrote:
3. Well I am surprised. If that is allowed, then I'll find some use for it indeed. I'll investigate.
MakeThms = Nothing won't work because "=" isn't supported for threads. If you do investigate Invalidate(), I'd enjoy knowing what you find out. I'm going to try out BackgroundWorker instead of creating my own thread. At first blush it seems less than intuitive to use, but probably safer.
Everybody SHUT UP until I finish my coffee...
|
|
|
|
|
Alan Burkhart wrote: MakeThms = Nothing
My mistake (and my rusty VB); should be If MakeThms Is Nothing Then (or IsNot). You should have known that, as should I.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
