Kevin Koltzau kevin@plop.org writes:
This is a ton of infrastructure for my future patches, and a full implementation of GetThemeDocumentationProperty which I primarilly used to test my INI file processing, and its now possible to set the current theme through the API..not that its much use to do that yet
The part about storing the string maps as resources seems unnecessarily complicated and inefficient. Why can't you store an array directly in the code?
The reason I did that was because of the large quantity of data, it was easier to define unicode strings in resources then it is to do in code, and I got a free method of seperating part/state data for each class As far as inefficent that wasnt my concern as the data is only loaded once at startup and never touched again If it is an issue I will change this and resubmit
On Monday 12 January 2004 04:57 pm, Alexandre Julliard wrote:
Kevin Koltzau kevin@plop.org writes:
This is a ton of infrastructure for my future patches, and a full implementation of GetThemeDocumentationProperty which I primarilly used to test my INI file processing, and its now possible to set the current theme through the API..not that its much use to do that yet
The part about storing the string maps as resources seems unnecessarily complicated and inefficient. Why can't you store an array directly in the code?
Kevin Koltzau kevin@plop.org writes:
As far as inefficent that wasnt my concern as the data is only loaded once at startup and never touched again If it is an issue I will change this and resubmit
Startup performance is definitely an issue. This is done for every app, and we are already doing way too much init work at startup, we should not add any more than strictly necessary.
On Monday 12 January 2004 07:07 pm, Alexandre Julliard wrote:
Kevin Koltzau kevin@plop.org writes:
As far as inefficent that wasnt my concern as the data is only loaded once at startup and never touched again If it is an issue I will change this and resubmit
Startup performance is definitely an issue. This is done for every app, and we are already doing way too much init work at startup, we should not add any more than strictly necessary.
Ok so the next question would be, how exactly would I define this? :)
my first thought would be something like MSSTYLES_MAP MAP_PROPERTY[] = { {TMT_STRING,TMT_STRING,((const WCHAR[]){'S','T','R','I','N','G','\0'})}, }; but in previous conversations that was decidedly a bad idea for portability reasons
I guess I'd probably need to define each string beforehand like WCHAR szString[] = {'S','T','R','I','N','G','\0'}; and use that in the map, but before I undergo that large task I would like to verify thats the best way
Kevin Koltzau kevin@plop.org writes:
I guess I'd probably need to define each string beforehand like WCHAR szString[] = {'S','T','R','I','N','G','\0'}; and use that in the map, but before I undergo that large task I would like to verify thats the best way
Either that, or you can declare a fixed-size array directly in the map structure and avoid the pointer indirection. It wastes a few bytes for short strings, but it saves some relocations, so it may be worth it if the longest string you have to store is not too long.
-
Alexandre Julliard -
Kevin Koltzau