Click here to Skip to main content
11,709,033 members (62,082 online)
Rate this: bad
Please Sign up or sign in to vote.
I had a general question, I'm wondering if I were to create a dll in another language (such as c/c++ for example, as those are what I'm familiar with) that ran an infinite loop and call it from a program how would I go about ending that infinite loop. To clarify, I would press a button on my vb program that would run this c dll, and in the c dll a function would be called that ran off of an infinite loop, while(1) let's say, my question is how would the vb program stop the c program?

Overall, and most significantly, my question is can I make a button/code in vb that will open and close a dll when it is pressed--rather than having the dll stay in use?

Edit: Also, if there are any resources on how to do this, tutorials, walkthroughs, etc. I would highly appreciate a link to them. I've found some stuff, but it's a bit cryptic to read through and in many cases not helpful.

Relevant info: OS: Windows 7 (64 bit), programming in code::blocks with mingw compiler for c/c++, and in visual studio 2008

To further elaborate on my question, what I want is a c program to indefinitely read from a file (the file is constantly filling) and a vb program to start and stop the process. Also, the data is supposed to be sent by an array from the c dll to the vb application so that the vb application can store and use the data as well.
Posted 19-Jun-13 1:56am
Edited 19-Jun-13 5:52am
Sergey Alexandrovich Kryukov at 19-Jun-13 8:23am
It all strongly depends on what is that "DLL": is it a native (unmanaged) dll or another .NET assembly (and then it could be created with C++/CLI).
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

The only way I know how to do it is to run the function on a separate thread, and then terminate the thread when you are done.

Look up threading and interop on google. .NET can generate interop assemblies for you in most cases.

Interop In .NET[^]
Sergey Alexandrovich Kryukov at 19-Jun-13 8:45am
You did not explain how to do it, and this is not a trivial thing. Second part of the question is also far from trivial.
Please see my answer.
(I did not vote this time.)
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

The scenario with the thread should be explained in more detail: you have to use such an non-trivial tool as System.Threading.Thread.Abort:[^].

In contrast to some common believe, it does not terminate thread. It performs such a non-trivial operation as exception seeding into the target thread. The exception is System.Threading.ThreadAbortException, you can handle it to perform some last clean-up action, the "last will" of the thread:[^].

In general case, if can be dangerous. You should use such things only if you understand very well what you are doing. But: if the code is hanging, it may means that it is already bad enough, so you simply don't have a better remedy in this situation.

Now, about loading and unloading. This is a complex matter which I would advise not to get into, unless you have extremely good understanding of technology. The kind of DLL makes dramatic difference.

If this is a native (unmanaged) DLL, you normally use it via P/Invoke:[^],[^].

This CodeProject article could also be helpful:[^].

If you invoke some methods in you DLL, you won't be able to load or unload it. (Again, you did not explain any reasons for doing it, so I would warn you against it.) If you really want to load and unload it, you would rather invoke Windows API methods and use them:[^],[^],[^],[^].

Now, about a .NET assembly. Normally, you just reference and use it. But can you load or unload it. Surprise: you are not allowed to unload a .NET assembly from memory, as it would be unsafe, not acceptable for memory-managed system — what if some code keeps access to some methods/properties of already unloaded code?

You can only unload the .NET assembly if it was loaded in some separate Application Domain. In this case, what you could do is to unload the whole Application Domain. But how to use the assembly if it is in a separate Application Domain? This is tricky.

If you want further detail, please see my past answers on this topic:
Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^].

Rate this: bad
Please Sign up or sign in to vote.

Solution 2

First, you don't have two different programs. The .DLL code is loaded into the address space of your VB.NET app. It becomes parts of your code.

If you start the inifinite loop on the startup thread of the app, then the loop will have complete control and your VB.NET code will not get anychance at all to run, so you can't stop the loop.

The way around this is to use any available threading methods in VB.NET, such a running the C method in a Thread or using a BackgroundWorker component. The problem with this is that you would have to modify the C code to look for some kind o bailout flag your VB.NET code sets to tell it to end itself gracefully. Don't use Thread.Abort. That's the very messy way to kill a thread, not shut it down gracefully.

Google for "VB.NET BackgroundWorker" for lots of examples.
Sergey Alexandrovich Kryukov at 19-Jun-13 8:54am
Sorry, but in the situation described by OP Thread.Abort is the last resort. Please read it carefully: there is no a graceful exit at all, in this particular case.

The danger of Abort is discussable, but many opponents don't have a clue and think this is something like TerminateThread, but it is not, not even close. When used with care, it can be used in a fully safe way (but of course, not in the case of some arbitrary code executed in the thread).

It would be safer to say that it should be used with care. As the general case is really unsafe, you can consider is as "better then nothing": the user can use such Abort and then do at least something, work just a bit more to complete important things, tolerating adverse effects of abortion of some code which provides no ways to clean up after abort. After all it may lead some resource leak, unclosed file handles, etc. But remember that the only alternative would be the termination of the whole process, which is of course much safer, but may mean the total loss of the user's current work. Abort is much better remedy in this case.

Dave Kreskowiak at 19-Jun-13 9:40am
I said don't use Abort because of the assumption that it's an unmanaged code DLL. It's a bad practice to begin with. If you have the choice, as he apparently does as he said if "he creates a DLL", then he should provide a gracefully exit, not a messy one. We have no idea what his "infinite loop" code does, so he could just as easily orphan resources with Abort. Better to take the safer route.
Dave Kreskowiak at 19-Jun-13 12:52pm
OK, who voted me a 1??

Granted, I didn't go into the post you did, but still, compared to Solution 4!! Come on!!

No, I'm not saying it was you SAK!
Rate this: bad
Please Sign up or sign in to vote.

Solution 4


The most simple way of ending a program will be to have a text or xml file, in which you can save the value of 1 or 0. If you want to end the program then simply save the value of 0 in that text file, which your function in Dll should detect and End the program. In this way there will be no side effects and the program will end graceously.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 580
1 Maciej Los 235
2 Peter Leow 219
3 OriginalGriff 214
4 Mika Wendelius 170
0 OriginalGriff 9,348
1 Sergey Alexandrovich Kryukov 8,727
2 CPallini 5,189
3 Maciej Los 4,991
4 Mika Wendelius 3,856

Advertise | Privacy | Mobile
Web01 | 2.8.150819.1 | Last Updated 19 Jun 2013
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100