|
It sounds like your thread is accessing the child form - maybe the progress control? - after the form has closed and been disposed.
Are you sure you want to cancel the thread when the form closes? Wouldn't it be better to allow the thread to complete? If you do want to cancel, you will have to add cancel logic to your thread method. Don't use Thread.Abort() ! If you want to let the thread complete, you will have to make it check if the form still exists before trying to access it.
BTW, Thread.IsBackground just means the thread will be killed when the main form is closed instead of keeping the process running until it has completed.
Nick
----------------------------------
Be excellent to each other 
|
|
|
|
|
I used Thread.IsBackground because I was thinking I wanted it to quit when that form was closed. It is a inventory application so if a user started saving a file that was 10MB and it was taking to long I was thinking I wanted to let them close it and I was trying to make it stop (not upload the file).
But I think I might go with the suggestion above and just refuse closing the form until it has completed. Just for my information if I wanted to do something like above, would it be easy to do? Stopping a cmd.ExecuteNonQuery(); that is uploading a file?
|
|
|
|
|
There is an IDbCommand.Cancel() method, but I've never used it.
Nick
----------------------------------
Be excellent to each other
|
|
|
|
|
I would do things a bit differently, in three ways...
1) Use a BackgroundWorker instead of a Thread (System.ComponentModel namespace). This can be set to raise ProgressChanged events on the GUI thread, so you don't have to deal with the invokes. It also has an IsBusy property that you can use when deciding whether to allow the user to close the form.
2a) Declare the worker at the form/window level, so you can kill it when the form is closing (Or not allow the close if it's running)
OR
2b) Create an IsBusy property on the form. Set it to true just before starting the thread/worker, and set it back to false when the worker completes (BackgroundWorkers have a RunWorkerCompleted event you can catch)
3) Instead of having the thread access form-level variables (Particularly if you use (2b) above, create a quick struct with the two strings and bool in it, and pass that as an argument to the thread/worker. It's preferable to have background threads be as self-contained as possible.
|
|
|
|
|
Ahh that is a great idea to.. using a struct.. so you are talking about this:
struct UploadFileInfo
{
public string TAG;
public string fileName;
public string safeFileName;
public bool fileMR;
}
private void saveFiles(object information)
{
UploadFileInfo fileInfo = (UploadFileInfo)information;
.............code.............
}
Thread fileThread = new Thread(new ParameterizedThreadStart(saveFiles));
fileThread.IsBackground = true;
fileThread.Start(upload);
|
|
|
|
|
|
Now that I think about it... the reason I am not using a background worker is because there are two different spots to save data. One is for normal attachments and the other is for M&R part of our inventory. I worked it into the same method to work both.
If I use a background worker I would hvae to create two seperate ones and create two seperate DoWork's. I think I am going to stick with the threading but not let the user close until their upload is complete.
Thanks again!
|
|
|
|
|
Jacob Dixon wrote: the reason I am not using a background worker is because there are two different spots to save data
there is a flaw in that logic. Just make a method (or even a separate class) that does it all (in any way you see fit, Thread, BGW, whatever), then call it from anywhere you like, and take precautions for it not to run twice at the same time.
|
|
|
|
|
In the form's Closing event handler I'd check on the thread and pop up a message that it can't close yet.
You could also have the thread disable the form's close buttons[^] until it completes, but that may be a bit heavy-handed.
|
|
|
|
|
I wanted to look up how the function TimeDiff is implemented exactly (a function to calculate how many hours there are between a start time and an end time) and found this. I'm not that experienced yet, so tell me... is there a way in which this might make sense or is this simply redundant and... well, stupid?
public static XDateTime TimeDiff(XDateTime d1, XDateTime d2)
{
#region Local Variables
#endregion
#region Actions
return APTimeDiff(d1, d2);
#endregion
}
APTimeDiff returns the same type and does the actual calculation (and formatting). Why put it into another function?
|
|
|
|
|
Well, its just a guess but one reason for doing this might be to avoid changing the public API of the class. So, once upon a time method TimeDiff did something different. Then it was decided to use APTimeDiff instead (maybe it's more efficient, maybe it handles some corner condition more effectively). But it might be that this is a library class which is used in a number of places, and for whatever reason we can't go through and change all the calls to TimeDiff to call APTimeDiff instead. So, just leave the old method in place but change the internal implementation. Any new code should now be using APTimeDiff, but old code that uses TimeDiff will continue to function as is and does not need changed.
It's a fairly common thing to do as part of a Refactoring process. Eventually, the aim would be to work through and replace all calls to TimeDiff with APTimeDiff.
|
|
|
|
|
It looks like half completed code, or post-refactored code which has not been cleaned up.
In the former case, the completion of that method would perhaps put some validation in to check the inputs.
In the latter case, the method may have been left as there are many places around the application calling TimeDiff and changing them all to APTimeDiff may be too time consuming at the current time.
|
|
|
|
|
Thanks guys, that makes sense. It is source code that has been passed on for many versions and many years, so it may very well be a change that has been made without cleaning the older parts up properly.
|
|
|
|
|
Is there something that I'm not understanding properly here? I've written a DLL that our customers can use to connect to our server and exchange certain info. On the one hand it makes it easier for them, not having to code a bunch of comms stuff and on the other hand it hides our exact protocol from them (or so I hoped).
When I use the DLL in my own test application and I set breakpoints in my code I can step right into the functions in the DLL. Surely it should be possible to avoid this? Any help please?
|
|
|
|
|
You can step into the DLL in your test application because it is debug compiled. You will provide a release compiled DLL to your customer. If you want to "hide" your code even more you can run it through an obfuscator, for instance dotfuscator.
|
|
|
|
|
Thanks for the reply. I will have a look at Dotfuscator.
Just to be clear, my DLL was indeed compiled with RELEASE configuration, not DEBUG. Now I'm not even sure what the difference is anymore as I always thought this was one of the key differences between the two configurations.
|
|
|
|
|
You can never entirely avoid leaking the code though. You can not depend on your code being secret. The CPU can still run the code, and everything the CPU does to be able to read the code is something the user could do as well. There is no solution.
A protocol is even harder to hide since they could capture their own internet traffic and analyse it.
But you can make it harder for your customer to read your code by using an obfuscator as indicated by Calla
|
|
|
|
|
It makes sense, thanks. I can understand that you can never prevent someone from decompiling your code but I would like for it to be a bit harder than this! It looks like Dotfuscator might do the job, I'll look into it, thanks.
|
|
|
|
|
Dewald wrote: Surely it should be possible to avoid this?
If it was possible to avoid, then there coudn't be any cracs and Keygens. The fact that reverse enginering is possible, it can be obscured, not prevented. Was that dll compiled with debug info? Is the Dll project in your solution with app project? If both question is yes, then you can easly debug dll and see it's source
you could compress the dll with UPX or other packer.
also look at this article: Strong Names Explained[^]
|
|
|
|
|
Thanks for the response. No, the DLL was not compiled in DEBUG configuration and no, the DLL project is not part of my app sollution. I have two sollutions, one for the DLL and one for my test app. The DLL sollution is compiled in RELEASE configuration and I then manually copied the .dll file into my test app sollution folder and added it as a reference to the project.
When I set a breakpoint on the line where I call a function in the DLL and I step into the line, it steps right into my DLL exposing all of the code.
Thanks for the article, I'll have a look at it and also have a look at UPX.
|
|
|
|
|
Then maybe you copied the PDB file as well? If no, I don't know how you could debug it.. (maybe VS tried to help you along the way in a very MS behind the scences kind of way).
To be sure how your DLL could be (mis)used by the customer I suggest you copy only the DLL file in a RELEASE compiled version to for instance a virtual machine with VS installed and then try and see what happens. From what I've experienced it is not possible to debug the DLL if you don't have any additional files (such as PDB) and you should be safe when it comes to stepping into your code. Then again, totally hiding the source is hard because of reverse engineering tools. Good luck!
|
|
|
|
|
I think you may be right about VS trying to help in a very MS behind the scene kind of way  , because I definitely did not copy the PDB.
Not too worry, I think this obfuscator did the trick (mostly).
Thanks for the help.
|
|
|
|
|
Debug vs. Release is not as clear cut in the .NET world as it was in something like C++. You can still debug release stuff.
What I *think* is probably happening is that you've still got a PDB file despite building in release. This is the file that tells the debugger how to map instructions to lines of source code. If you don't distribute that, then they shouldn't be able to step in the debugger. Also, they'd have to have the source code anyway which they won't.
It's by virtue of the fact you have both source and PDB on your machine you can do it, so no, they won't be able to step through it.
As other's have mentioned, it's very straight forward to reverse engineer .NET with something like Reflector. You can obfuscate it, but that's not that effective. Really, if you need to protect some Intellectual Property you'd need to use something other than .NET, or maybe managed/unmanaged C++. But, ultimately, anything can be reverse engineered.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: Debug vs. Release is not as clear cut in the .NET world as it was in something like C++.
I'm giving a 5 for that.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
This is all very interesting, thanks. I am perplexed though because I know for a fact that my test app and my dll are in separate solutions in separate folders. I definitely did compile the dll in release config and, while the compiler did create a .pdb file (in the release directory) I only copied the .dll file into my test app's folder.
At any rate, I fiddled around with Dotfuscator a bit and I seem to have gotten to a point where the .dll is ugly enough to at least dissuade the average programmer from decompiling it and at least I can't step into the code in debug mode anymore.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
