|
Thank you, Luc.
Actually, I didn't think existing code would cover what I need. Basically I wanted to know if bit-shifting can be done with a matrix at all. If yes, the next step would of course be to ask how such a custom matrix would be coded.
Luc Pattyn wrote: replace them by local variables, local code, and larger moves (say a scanline at a time)
Ok, replacing the array's length was easy and I hope I replaced the byte-swapping properly by reversing the whole byte array (Array.Reverse(RGBArray)). What I don't quite understand is how you would address "a scanline at a time" and still get the right RGB values for each and every single pixel?
|
|
|
|
|
you should load a number of pixels into a local array, not call them one by one. So replace readUint32 by whatever fits the situation.
I did not suggest you reverse an entire array, that is an expensive operation (especially if the image size exceeds the L2 cache size) that doesn't raise the intrinsic value of your data. What I would consider is calculating each pixel component from the exact two bytes that hold its bits.
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.
|
|
|
|
|
I want to change the verion number of XLA project,this is existing project
please help me thanks
|
|
|
|
|
1) Double Click 'My Project' in 'Solution Explorer' pane.
2) On the 'Application Tab' click the 'Assembly Information' button.
3)Set new version number as required.
Or, Right Click the Top Level Project Node and Select Properties, perform steps 2 and 3 above
Or, from the Project Menu select 'AddinName' Properties, perform steps 2 and 3 above
|
|
|
|
|
According to MSDN, to change the NameSpace of a project all I have to do is just type the new name in the textbox in Application Properties. But when I do that, the app won't run. I get an error in the Settings Designer.
This may or may not be relevant: When I first began the project it wasn't even intended to be saved - I was using a new separate project to work thru a problem with programmatically altering a TableLayoutPanel. But I decided to save it and changed the name in the VS SaveAs dialog. So now the root namespace and the assembly name are different. I'm wanting to use the assembly name for the root namespace.
What to do?
Everybody SHUT UP until I finish my coffee...
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
