Did you try to do just what the compiler suggested, that is including "stdafx.h" to cinsim.h? I did the testing on my Linux box where there is no "stdafx.h"...
@MaKaKaZo: You kidding? CInSim is the best InSim lib out there, simple enough to not do anything weird behind my back, yet fully functional and easy to use.
That's kind of weird, do you have any idea where exactly it crashes? You can put few std::cerr's to the code to track it down. BTW, do you use pthreadGC2.lib and not pthreadVC2.lib with Code::Blocks?
Have you made any substantial changes to the code, or can I use the version you've already uploaded? I'll see if I encounter the same problem as you with Code::Blocks...
I can help with this! This is a problem that comes from mingw compiler code optimization options. I think there were three levels of code optimization in the compiler options. If you check some of them *sometimes* it will generate an executable that crashes. This has been reported in mingw support several times, it has nothing to do with code::blocks, CInSim or my application. It works when debugging because in debug mode no optimization options are checked. You can just uncheck some of the optimization levels until you get a working executable.
This actually got me crazy some time ago when I did some minor changes to a project and suddenly it started crashing for no reason.
With you VS problem I can't help much. It's pretty clear that it's something to do with the includes, libraries and such. I'm no expert at all at that matter neither I know about VS as I have never used it.
I couldn't get the Code::Blocks project to build (MinGW linker refuses to find the pthreads lib and I don't have the nerve to solve it right now), but I got the MSVS project working. There was just one #include "stdafx.h" missing in the main.cpp
This is *only* important if you have a multi-threaded application.
As I recall, I used those functions inside the main application code in earlier versions of CInSim, but soon I realized that I could just put that code inside the library code itself, so the programmer doesn't need to control mutual exclusion.
The thing is, if you have an application where multiple threads are created, and those threads use common resources (ie. global variables), then it could happen that those resources might be used by both threads at the same time, resulting in undesirable consequences.
Please tell me which file you are viewing that code in (and CInSim version used) and I'll go into deeper detail of why I used it, but I'm pretty confident that it has to be something related with the main application algorithm, not with the library. I mean, it isn't supposed to be something that has to be used for all CInSim applications!
Mutex in question is handled internally in CInSim 0.6, so you don't need to explicitly lock it in your application. It's needed because there are two threads (one for receiving TCP and another for UDP packets) which both call the send_packet function. Packet sending has to be an atomic operation and the mutex is there to make sure that one thread doesn't get interrupted by the other one when sending a packet.
You shouldn't have to, CInSim v0.6 is thread-safe in this respect. If you take a look at "send_packet" or "send_button" in CInsim.cpp, you'll see it's locking a mutex before calling the "send" method.
That's right. X-Y-Z positioning was my first attempt on an insim app using buttons and MCI packets. It's very old and uses an earlier version of CInSim. As Madcatx said, CInSim 0.6 is thread safe already so you don't need to use them.
Actually, aside from what has been already mentioned about UDP and TCP using the same method for sending packets, my main concern was using the same method frmo different threads.
For example, I usually create new threads that act as timers. They are created, wait for several seconds, and then they do something like clear a set of buttons that were created previously (this is the way I create a message that automatically disappears after X seconds). This timer thread has to use the send() method. If you have several threads like this doing different stuff, there's quite a high possibility that at some time two of them will try to use the method at the same time, and the result might lead to a unstable status or even a crash. It actually happened to me before I fixed it.
CInSim 0.6 blocks the critical methods before using them, so that only one thread can use them and calls from other threads are queued until the current one finishes. You don't need to handle that manually anymore.
If you are interested in CInSim maybe you should download the latest demo application which uses the latest CInSim version (I think... ).
Your "send_mtc" function seems to be OK, I tried it now it worked for me just fine. I hardcode the size of the Text array to 128 in insim.h and send the IS_MTC like this (msg is 127 chars long). It appears in LFS all right and my sample program doesn't crash...
Why don't you just copy and edit the send_button() function? It's exactly the same case and it works fine.
BTW, there's a mistake in your code because you use the field "Msg" in the IS_MTC, but now it's called "Text".
I'll change the library source code with the new insim changes when I have some time. It's a quite simple task. The good thing is that it will be backwards compatible. We will have a new send_mtc() function to send variable sized mtc packets, but the generic senc_packet() will work as well, causing a little network overhead because in that case packets sent will be the biggest possible (with 128 bytes of text).
-
(denis-takumi)
DELETED
by denis-takumi : I love C++
or with Denis' code to handle a situation when you have say 12 chars long string ending with zero terminator. In this case "strlen" returns 12 but you actually need to send 13 bytes where the 13th byte is '\0'. If you don't do that, LFS gives you "Last byte must be zero" error. (I found that the hard way today )
I was also thinking, wouldn't it be better to have just "send_packet" function and overload in accordingly to handle different packet types? If InSim ever gets more packets with variable size, having a different function to send each of them would get rather inconvenient...
).
