|
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!
|
|
|
|
|
That assumption is why we have the problems with int, long, and void* today. In the 32-bit standard, they were all the same size, so programmers would take advantage of that and cast 32-bit pointers to integers. The problem is now that when you want to run a 32-bit application on a 64-bit platform, that assumption breaks your code (not desirable).
To prevent this from happening, one of the proposals being discussed is to create a long long datatype for 64 bits, long and int would still be 32 bits, short would still be 16 bits, and char woudl still be 8 bits. void* would be 64 bits.
As for the ULONG_PTR and INT_PTR ... those are just typedefs (use to be #define's). They are handy for recompiling in 64 bit mode, but still run into the same problems when you try to run a 32 bit application on a 64 bit platform. The presense or absense of those definitions has nothing to do with the actual compiler and everything to do with the utility libraries. You can VERY easily create your own.
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
|
|
|
|
|
Alexander M. wrote: Using a 32-bit compiler, sizeof(long) = 4.
But what about 64-bit?
On Windows, still 4.
On most Unix-like systems: 8
In general: implementation dependent.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|