To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=83014





------- Additional comments from [EMAIL PROTECTED] Mon Nov 26 12:57:42 +0000 
2007 -------
I strongly second the opinion of Armin here, IMHO changing the
tools/inc/tools/contnr.hxx values to ULONG_MAX instead of a fixed 32bit value in
cws sixtyfour11 was wrong in the first place. There are too many
interdependencies as you can see..  I also don't think that making those old
container structures use 64bit is actually wanted.

However, as for svx/source/dialog/numfmt.cxx the change mentioned in #desc14

-#define NUMKEY_UNDEFINED ULONG_MAX
+#define NUMKEY_UNDEFINED SAL_MAX_UINT32

should do it, but the
    if ( aLbFormat.GetSelectEntryPos() == LIST_APPEND )
is a total mess now. The code anyway doesn't work with more than 32k entries,
see all the aLbFormat.*EntryPos related short and USHORT values. Looks like
changing the return value of SvxFontListBox::GetSelectEntryPos() to 32bit was a
half-hearted approach, as SelectEntryPos() still takes only sal_uInt16 values
and LISTBOX_ENTRY_NOTFOUND and similar listbox control structures are still
16bit. Note that in early days all containers were limited to 64k entries ...


---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to