15,898,134 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View Python questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by AS01234 (Top 9 by date)
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?
Show More