Wow! Thanks for the ascending/descending sort toggle in popups.

One minor issue - Column sorts on oconv'd data rather than the iconv'd value, so date sorts may not be as expected.

Warren,

Wait until you see this in 7.1.1! Carl did a great job of making this appear even more like the Windows standard.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

I can't wait…the product keeps getting better and better in leaps and bounds :)

Mike and his krewe and the whole ARev/OI community are doing a wonderful job.

Warren-

This was fixed some time ago - perhaps 4.1.3. Are you really seeing it? Is the Oconv in the popup record, or are you doing it manually?

Mike

Popup is templated in UI Workspace. We pass a list of keys to it. Date column is defined in template with an User Conversion, which is just a standard user defined conversion that we replace for the proper format for our international sites. Date is stored in normal internal format.

I tried replacing the format to "D2/" in the popup layout but still get the same sort results.

Just tried this in 7.1 and received the same results that Warren did.

The popup is based on a key list and there are more records than will display in one scroll (5097). the date field is right justifield and has a D4/ for oconv. The order seems to be fairly random. I would send a screen shot but don't know how to do that and past it into this message.

John

It appears to work correctly in 7.1.1 but not in 7.1

dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Was the popup done displaying?

That is, if you move the scroll bar down some, did it start creeping back up?

The popup was fully populated in my case. But if it's fixed in v7.11 I guess it's a moot point.

I haven't tested this in 7.11 and it still does not work.

Mike, I am forwarding screen shots for you via email. Sorry don't know how to attach them to the Works Discussions.

John

Okay, I tested this in v7.11

Does not sort on iconved value on a user defined conversion. Works okay with standard conversions (i.e. D2-, D2/)

Since we have international sites we use a user conversion that is set to do the OCONV in accordance to local standards. In ARev we would just swap out the INTL.BP file which contained all the user conversions. Code as follows:

SUBROUTINE DT_CONV(CONV, VALUE, BRANCH, RETURN.VALUE)

common /CONV/ CONVPSEUDO Declare Subroutine MSG Declare Function MSG * * THIS IS A USER DFINED CONVERSION SUB FOR USE ON DATE. EQU DBUG$ TO 0 * EQU IN TO "D" EQU OUT TO "D2-" * PROGRAM.NAME =DT_CONV V1.00" * * Subroutine declarations * Local Equates * The STATUS() variable is used to indicated the error condition of the * pattern. They are: EQU VALID$ TO 0 ;* SUCCESSFUL EQU INVALID_MSG$ TO 1 ;* BAD DATA - PRINT ERROR MESSAGE WINDOW EQU INVALID_CONV$ TO 2 ;* BAD CONVERSION - " " EQU INVALID_NOMSG$ TO 3 ;* BAD BUT DO NOT PRINT THE ERROR MESSAGE WINDOW EQU ERROR_MSG$ TO 'Invalid input data passed to ' IF DBUG$ THEN CONVERTDUMMY=MSG(Parent, PROGRAM.NAME : "|VALUE PASSED= : VALUE)

END

*

BEGIN CASE

CASE CONV=ICONV"

RETURN.VALUE =ICONV(VALUE,IN)

CASE CONV=OCONV"

RETURN.VALUE =OCONV(VALUE,OUT)

CASE 1

CONVERT__DUMMY=MSG(Parent, "INVALID CONVERSION MODE PASSED TO " : PROGRAM.NAME)

STATUS() =3

RETURN.VALUE =ANS

END CASE

RETURN

Does not sort on iconved value on a user defined conversion. Works okay with standard conversions (i.e. D2-, D2/)

Is it appropriate to sort on the iconv value for user defined conversions in the general case? I wouldn't think so. There isn't anything to suggest that a general iconv format should be sortable. It could be meaningless data from the user perspective - a system generated id for instance. The Oconv value is what the user sees and so is a better choice for sorting as it would at least always sort according to some visible pattern.

Just my 2c (NZ)

M@

[img]http://www.vernonsystems.com/images/logo_main.gif[/img]

If that were the case then RLIST SELECTs and SORTs would do so on the OCONVed value depending upon the conversion specified in the dictionary descriptor, which defeats the purpose of having internal formatted data. If I want to sort on the external/visual format I normally create a symbolic which oconvs the data in the formula and does not have a conversion specified in the dictionary.

Now come on folks!

Could I really tell my clients that an oconv date sort is logical in that it's alphabetically sorted in the order April, August, February, December, January, July, June, March, May, November, October, September?

Get back onto this planet!

Surely the answer has to be that the sorting in sortable popups, etc. must be switchable column by column to use iconv or oconv as appropriate.

RTI - in 7.1.2???

1) I don't have a quick answer for the popup sort – I agree with Matt that always sorting on Iconv value for user conversions could break existing apps. Thus, as Richard suggests, this should be an option on the popup definition screens, which affects various routines and equates. Such a change would bneed to be part of a release.

2) Following up on Warren's date routine, check out LOCALE_DATE_FORMAT, a routine included in OI 7.1.1

It uses the Windows api to get the user's country settings, then maps that to OI date conversions. Won't affect the popup issue, but might be useful. Requires getLocalInfo to be prototyped, which is true for OI 7.1

Bob

subroutine Locale_Date_Format(conv, ans, branch, return_data)

/*

*

* Use Locale Settings for Date

*

* It should be placed in square brackets, like this:

*

* Locale_Date_Format, LocaleId

*

* This subroutine should be used as the first and only "Input Validation" in

* a window prompt. Placed in "Output Format", it properly formats any

* reasonable string into a date, using info from the windows Locale

*

* Note:

* Use Branch to pass in a windows locale identifier to override the default locale.

* By default the routine uses the system locale.

*

* See the following link for a list of locale codes

* http://support.microsoft.com/default.aspx?scid=KB;en-us;229690

*

*

* This routine is a partial implementation

*

* The full implementation of the formats is described here:

* http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceinternational5/html/wce50lrfgetdateformat.asp

*

*

* 10 Feb 2005 rjc Created

*

*/

* Subroutine declarations

declare function getlocaleinfo

$Insert LOCALE_EQUATES

* Local Equates

* The STATUS() variable is used to indicated the error condition of the

* pattern. They are:

EQU VALID$ TO 0 ;* Successful

EQU INVALID_MSG$ TO 1 ;* Bad Data - Print error message window

EQU INVALID_CONV$ TO 2 ;* Bad Conversion - " "

EQU INVALID_NOMSG$ TO 3 ;* Bad but do not print the error message window

* Begin Conversion

*

localeId=Branch

if localeId else

localeId=LOCALE_USER_DEFAULT$

end

return_data="

if ans ne "" then

transfer ans to work

ans="

LocaleType=LOCALE_SSHORTDATE$

gosub getLocaleInfo

transfer localeinfo to dateformat

LocaleType =LOCALE_SDATE$

gosub getLocaleInfo

transfer localeinfo to dateSeparator

if len(dateSeparator) then

	convert dateSeparator to @fm in dateformat

end else

	convert '.' to @fm in dateformat

end

firstElement =dateformat

secondElement=dateformat

ThirdElement =dateformat

• Build a Rev conversion string from the Ms version

OiFormat =D'

• Year Format?

y_col=indexc(dateformat, 'Y',1)

y_fld=count(dateformat1,y_col, @fm) + ( y_col ] 0 )

if y_fld then

	y_string=dateformat

	y_len=len(y_string)

end else

	y_len=4

end

OiFormat := y_len

• Separator ?

OiFormat := dateSeparator

• European or US ordering ?

if firstElement1,1 _eqc 'd' then

• if len(dateSeparator) then

• OiFormat := 'H'

• end else

		OiFormat := 'E'

• end

end

• Short, Medium, or Long month ?

m_col=indexc(dateformat, 'M',1)

m_fld=count(dateformat1,m_col, @fm) + ( m_col ] 0 )

if M_fld then

	m_string=dateformat

	m_len=len(m_string)

end else

	m_len=1

end

begin case

   case m_len  0 then

LocaleInfo=buffer1,ret - 1

end else

LocaleInfo="

end

return

Okay, I can see the point about the sorts. As Richard suggests, perhaps adding a checkbox on popup layout designer to always sort on iconv value would work. Otherwise sort as it does now.

The localization routine you posted looks interesting, but since we're still a mix of ARev and OI it may not be ready to implement into our system. Besides we deal with units of measure which need to be localized also.

View this thread on the Works forum...