|
pblais wrote:
char data_1[] = {1,1,12,0};<br />
<br />
char i_loop1 = 0;<br />
for(i_loop1 = 0; i_loop1 <= data_1[1] + 1; i_loop1++)<br />
data_1[3] ^= data_1[i_loop1];
This isn't the best way to initialize an element of an array (nor declare one actually). It likely isn't the cause of your problem, but very well could be if you ever changed the size of the array. A better way to write it would be:
<br />
char data_1[4] = {1, 1, 12, 12};<br />
It is more efficient and decreases the chance for an error to sneak in the code.
For your second issue, if the next area in memory is getting trashed when you change the size of the array, look for something that is assuming a memory location (since this is a hardware simulation, I wouldn't be surprised to see a few). Also look for code similar the the segment above that writes to something out of bounds when dealing with the ROM_Buffer of a different size.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: For your second issue, if the next area in memory is getting trashed when you change the size of the array, look for something that is assuming a memory location (since this is a hardware simulation, I wouldn't be surprised to see a few). Also look for code similar the the segment above that writes to something out of bounds when dealing with the ROM_Buffer of a different size.
Hi again Zac... I've been playing around since I posted.... By the way thanks for the help on the first part...
Anyways... The array below ROM_Buffer (RxBuffer) is affected but not really any code is run
In the main dialog:
MYDLL = new APM_Driver;<br />
bTestVal = DUT->RxBuffer[1]; <------BREAK ONE HERE<br />
Then in the APM_Driver.cpp file:
<br />
APM_Driver::APM_Driver()<br />
{<br />
baud_rate = 19200;<br />
SelectComms();<br />
}<br />
<br />
APM_Driver::~APM_Driver()<br />
{<br />
delete comms1;<br />
}<br />
<br />
void APM_Driver::SelectComms()<br />
{<br />
int i_c;<br />
<br />
<br />
for(i_c = 0; i_c <=255; i_c++)<br />
RxBuffer[i_c] = unsigned char (i_c);<br />
<br />
for(i_c = 0; i_c <=255; i_c++)<br />
TxBuffer[i_c] = unsigned char (i_c);<br />
i_c = 1; <------BREAK TWO HERE<br />
}<br />
As you can see comms1 = new CCommsDriver1; has been commented out. SO the only code that is executed are the two small loops that initialize RxBuffer and TxBuffer to 0->255. Yet when I break the code at BREAK TWO, both buffers are ok but when I stop at BREAK ONE, MYDLL->RxBuffer is trashed.
Thanks
Pierre
|
|
|
|
|
Its hard to say. Nothing in the code you've shown sticks out as a potential problem. Your best bet is to start commenting out code in your application code (not the dll) to get to a point where absolutely everything "works" (that is, no memory problems), and then to slowly umcomment blocks until you see the problem. With these types of issues, sometimes that is the only way to track it down.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
well this is mine problem so far. i have some papers(formulars), and i want to print into them preciesly. what should i do since i can't change them 'cos they are allready printed and cannot be changed in any way. pls anyone who has some knowledge, help. btw mine application has some edit boxes, and i want to print their contents into my papers(formulars). pls help and many thanks
ivan
|
|
|
|
|
Hello!
This is my first post on the Code Project, maybe you can help me.
In my dialog box I have a list view and a check box.
If the check box is unselected, the user should be able to select any list item they wish.
However, if the check box is selected, and there are only two list items, I want both list items automatically selected as it is a requirement of my application (right now, the user has to Shift select both list items before proceeding, and I want to remove this ambiguity by having both required list items selected for them).
However if there are more than two items in the list, there should be no automatic highlighting.
That said, I'm not sure how to go about this in Visual C++ .NET. Any suggestions?
Thank you. 
|
|
|
|
|
|
Mike, where the FAQ says:
Here is how to select an item whose index is nItemToSelect:
wndYourList.SetItemState ( nItemToSelect, LVIS_SELECTED,<br />
LVIS_SELECTED );
does "index" refer to an actual number? for example, if I have 2 items in my list, would the first item be index "0", then index "1"?
any others have alternative suggestions? (sorry, I am a novice)
|
|
|
|
|
aafcls wrote: does "index" refer to an actual number? for example, if I have 2 items in my list, would the first item be index "0", then index "1"?
Index refers to the item number, but it isn't necessarily in order (if you allow sorting your list items, it will be highly random). You should just need to call CListCtrl::GetItemCount to see how many items there are in the list and if there are 2 or fewer, use CListCtrl::GetNextItem with the default flags to get the item index. After that, use the index in your CListCtrl::SetItemState call.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
Thanks, this works.
However, instead of selecting each item by index number, is there a way to "select all"? (instead of having to do individual SetItemState)
|
|
|
|
|
|
Does anyone know what is going on here???
typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
|
|
|
|
|
|
Why do we have a typedef in front of this function of type void
typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
|
|
|
|
|
It is defining a function pointer. The syntax is a bit quirky since most people try to write it like this:
typedef (void UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
It is basically declaring a type called UpdateHandler that will be able to point to functions with the following signature:
void f(ObjectRootPtr, const RTI::AttributehandleValuePairSet&);
These are typically used as callback functions.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Jay03 wrote: typedef void UpdateHandler(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
That is odd, usually you'd write it as:
typedef void (*UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&); which makes the new function pointer type UpdateHandler
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
VB > soccer
|
|
|
|
|
It might be useful to declare the calling convention if you are exporting these pointers from DLLs for example.
typedef void (__cdecl *UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
typedef void (__stdcall *UpdateHandler)(ObjectRootPtr, const RTI::AttributeHandleValuePairSet&);
...
Don't try it, just do it! 
|
|
|
|
|
Hello everyone,
I have a question concerning the long data type. Using a 32-bit compiler, sizeof(long) = 4.
But what about 64-bit?
Regards,
Alex
Don't try it, just do it!
|
|
|
|
|
long is still 32-bits in a 64-bit compiler. If you want to have a 64-bit integer, use long long (platform independent) or __int64 (Windows).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
short int is the same as short
long int is the same as long
sizeof(short) returns 2
sizeof(long) returns 4
on a 16 bits environment : sizeof(int) returns 2
on a 32 bits environment : sizeof(int) returns 4
on a 64 bits environment : sizeof(int) returns 8
sizeof(long long) is supposed to return 8, but it is not provided by the standard, and not every compilers know that type.
sizeof(__int64) is quite the same as long long, but AFAIK, it is a microsoft specific type, so, not portable either...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
toxcct wrote: on a 64 bits environment : sizeof(int) returns 8
This is not currently the case, and many on the standards committee are arguing against making it so for backwards compatibility reasons. Currently, on 64-bit compilers, sizeof(int) will return 4 (just like on 32-bit compilers). sizeof(long long), which most compilers support and is being discussed as part of the next standard, will return 8. sizeof(void*) will return 8 on a 64-bit compiler.
Note that much of that is still subject to change ... we should know for sure when/if the standard's committee is able to agree on things by 2008.
As a side note, it is best to declare the type of integer you actually want (or typedef it) instead of declaring "int" for precisely this reason. If you need low numbers (less than 255/127), use unsigned char/char; if you need larger numbers, use unsigned short/short; and if you need huge numbers, use unsigned long/long. Finally, on 64-bit systems, if you really need the massive numbers, use unsigned long long/long long. It will help save you some portability issues down the road.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
-- modified at 13:30 Thursday 22nd June, 2006
|
|
|
|
|
Zac Howland wrote: use unsigned long long/long long. It will help save you some portability issues down the road.
I'd recommend using typedefs and __int64. That's far easier to maintain, should long long mean anything else than 64 bits on a specific platform/compiler.
My 2 cents. 
--
100% natural. No superstitious additives.
|
|
|
|
|
I agree with the typedefs, but __int64 only means something for Microsoft's compiler. If you use any other compiler, it is meaningless (or you would have to typedef it to long long).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I see that I didn't really express what I meant. I really meant that the typedef should be changed to alias to the platform specific 64 bit type. (And not just the microsoft __int64 type)
--
100% natural. No superstitious additives.
|
|
|
|
|
That standard is so stupid... they should use long as synonym for char *, which makes pointer arithmetic easier. At the moment there is a big problem when you want to cast a pointer to an integer, especially if you are creating source code for different platforms and compilers. Windows defines ULONG_PTR etc, but I've never heard of a Linux equivalent 
VC++ and GCC are also very different in some cases, that's getting on my nerves...
Thanks for your answers!
Don't try it, just do it! 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
