Comments by AS01234 - CodeProject

AS01234 28-Jun-20 14:13pm View

Thank you all. I discovered the problem when I was simply trying to change the color of a button for a timed period and then change it back to the original color, in order to indicate that a program finished an activity that it was doing in the background. Then I simplified it down to this two-line example. This seems like a very common situation, and it is disconcerting that the Forms controls are behaving in such unexpected ways. I think a work around for my need is to change all of the button colors at the beginning in Form1_Load. What a pain-in-the-neck.

AS01234 15-Sep-13 11:31am View

Unfortunately, I can't seem to accept your solution, so I have to select "solved myself" even thought that is certainly not true

AS01234 15-Sep-13 11:29am View

Jason, see below. I accepted your solution, in the sense that everything that you suggested led to the conclusion that nothing was wrong.

AS01234 9-Sep-13 21:28pm View

Thank you Jason for all of your help.

If nobody else can figure out anything wrong with the original code, I am forced to conclude (a la Sherlock Homes) the least likely thing: the dll is actually returning the crazy numbers. If so, it is certainly irritating that they would return number that are so out of range while also returning 0, which is supposed to mean a "successful result."

I have a question into the Tucsen camera company, and I also directed them to this question. I will get back to you (and perhaps with the rest of the world) with a report on how helpful they are. I would be thrilled if they are even a tenth as helpful as you have been.

AS01234 7-Sep-13 8:26am View

Just after calling TC_getRoi, hei=8024. I inserted the line:
Byte[] bytes = BitConverter.GetBytes(hei);
The result was Byte[] = {88, 31, 0, 0}.

AS01234 6-Sep-13 14:00pm View

Thank you again for your reply. I tried:

Int32 pointxTest2 = BitConverter.ToInt32(bytes,0);
UInt32 pointxTest3 = BitConverter.ToUInt32(bytes,0);

Both give the same value as noted above. (I guess the int and uint are the same in this case because the values are less than half-way up the range.)

AS01234 6-Sep-13 12:07pm View

Thanks again for the reply. I tried the little endian idea, and when I reverse the bytes (but I didn't understand the padding issue), I get other crazy numbers.

This also answered the second suggestion about the depth. When I use:

Byte[] bytes = BitConverter.GetBytes(pointx);

the result for bytes is a 4 element byte array, so I am pretty sure that c# is using 4-byte int (equivalent to int32). I am less sure about the c++ int, but I am running this on a fairly standard 32-bit machine. Can a c++ int be different than 4-bytes?

I am already breaking on the line before and after the call to the pinvoke (TC_getRoi), but my vs2008 does not let me put a break right on the pinvoke itself. So I cannot seem to see that critical external call. When it stops just before and just after the call to the pinvoke TC_getRoi, I can look at the Call Stack tab, and it shows the call into TCgetRoi, which does not tell me anything new. I am not sure that this is what you mean whey you say "look at the stack," and you might be referring to a trick that I don't know. In visual studio 2012 there seems to be a "show external code" option that I do not seem have in visual studio 2008.

Unfortunately I don't have the c++ code for the dll itself-- just the .dll file itself.

If everything looks right, should I conclude that the dll is really sending back the crazy values? It is remotely possible that there is a subtle difference in the preceding calls to the dll that could make it return crazy values. When I run the c++ example I add break points to the calls to the dll, and everything looks pretty much the same as in my c# program. This is why I still consider this an unlikely possibility. Before making this conclusion, I would love to see if anyone else finds anything wrong with the original code.

AS01234 6-Sep-13 9:59am View

This looks the same as what I had. Just in case there might be a difference that I did not see, I copied and pasted it in, and it still gives the same crazy result. Do you think that the dll might actually be returning this crazy result? It still seems more likely to me that I am not marshaling it properly.

AS01234 8-Aug-12 12:17pm View

I couldn't tell from the listing: Did it properly go to the c# discussion board?

Comments by AS01234 (Top 9 by date)