Herewith a copy of a page from our experimental Tornado Toolkit web site area in case it is of interest and use to others. Hope it come through intelligibly! ….

This page discusses three annoying problems with OI's standard POPUP facility two of which which I have raised as nauseam with RevTech but nothing whatsoever has been done about them!

Fortunately the source code of POPUP is included in recent versions of OI and it is therefore possible for the foolhardy like me to tweak it.

Before doing anything make sure you have a safe copy of SYSOBJ $POPUP and of SYSPROCS POPUP.  Note also that you'll probably have to copy POPUP to another name as the system won't recompile a modified copy of POPUP and then copy your new object code to overwrite $POPUP.  I alias the OI tables from ARev for this sort of mischief.

Null Selection in Preselected Multi-Select Popup

The scenario…  Your program calls a multi-select popup and preselects one or more rows in the popup.  You user does his stuff and POPUP returns null.  Did the user press escape (i.e. the previous selection still stands) or did he simply deselect all and click OK(he wants a null selection)?  Answer: you cannot tell.

Solution: Circa line 125 insert a line after "if len(PopupRec) then" and "transfer PopupRec to Popup_Struct@" reading

If PopupRec then Ret=\1B\;Popup_Retval@=\1B\

This sets the popup return value for a preselected popup to the Escape character unless the user makes a positive (if null) selection.  Thus if a preselect popup returns \1B\ the user aborted whilst if it returns null he nulled the previous selection.

Double-Click Sorts Dates Wrong

With a "sortable" popup double-clicking a column title sorts the popup on that column (or shift double click does a descending sort).  The sort is performed on the text displayed in the popup and therefore dates and date-times don't sort correctly.

This is a bit trickier as the data in internal format is converted when the popup is displayed and the output conversions are not subsequently stored.  We'll therefore have to find a temporary home for this info.

Around line 295 after the comment "* perform output conversions …" and before "for Col=1 to popup_ColCount@" insert a line reading

OCVS="

then a few lines later after the line "Conversion=Popup_Oconvs@ add a line reading

OCVS=Conversion

then a few lines later after the line "Next Col" add a line reading

Call Set_Property(@Window , "@OCVS" , OCVS)

thus we are storing a user property for the popup window called @OCVS and containing the output conversions used to write the display

Next we need to tweak what happens when the user double-clicks a column containing dates.  Go down to around line 543.  After the line "if bitand(GetKeyState(16),32768) …" insert the following lines

Declare Function Get_Property

OCV=Get_Property(@Window , "@OCVS')

If OCV1,1=D' then

  Call Set_Property(@Window , "REDRAW" , 0)

  ColData=Get_Property(@Window:ET_Popup$ , "DEFPROP" , Col)

  Call Set_Property(@Window:ET_Popup$ , "DEFPROP" , IConv(ColData , OCV) , Col)

  PS_Set_Property(@Window:ET_Popup$, "SORTEDCOL" , Col:@FM:Sort)

  ColData=Get_Property(@Window:ET_Popup$ , "DEFPROP" , Col)

  Call Set_Property(@Window:ET_Popup$ , "DEFPROP" , OConv(ColData , OCV) , Col)

  Call Set_Property(@Window , "REDRAW" , 1)

and alter the existing "PS_Set_Property(@Window:ET_Popup$ … line to read

end else PS_Set_Property(@Window:ET_Popup$, "SORTEDCOL" , Col:@FM:Sort)

There are lots of ways of doing this but I think you'll see quite easily how this one works.

As usual, on your own head be it!

Literal Popup Column Spec Ignored

In the popup spec you can specify in each "format" column (field 9 of the spec) which column should be used from the file records or, in the case of a "literal" popup, from the records in the "display" spec (field 8 of the spec).

In Arev this worked fine. In OI it works for "R" type popups - but for "L" type popups the columns specified in field 9 are simply ignored and the columns from the literal data are chosen in order - 1, 2, 3, 4, etc.

This is VERY annoying. To correct this problem add the following lines at the same location as the null selection correction described above :-

If PopupRec=L' then

NuFields='

Nf=1+Count(PopupRec,@vm)

Nr=1+Count(PopupRec,@vm)

For iField=1 to Nf

  For iRow=1 to Nr

    NuFields=PopupRec]

  next iRow

Next iField

PopupRec=NuFields

end

Again - at your own risk! I have only tested R and L modes - but, if it affects other modes the fix should be very easily adapted.

I am so pleased that Revalation did supply the source code for the POPUP function.

My customers complain about the sorting also. For instance, the Invoice field is alpha-numeric. Some of my customers say that they only use numbers and want the field to sort right justified not left justified. I tweaked it so that holding down the "CTRL" key would sort using a right justify to a left justified field.

Same thing with the "SHIFT" key and assending and desending.

I truly appreciate Revelation for offering the source code so things like that are allowed.

Richard

I couldn't agree more about availability of RTI source code!

I haven't got too deeply into RTI's code - but when necessary it's vastly better to do something quickly rather than tear one's hair out waiting for the (necessary and understandable) procedure for RTI to consider a mod and then maybe schedule it, do it and finally release it!

I've had to have a bit of a field-day with RDKMODULEINSTALL - e.g. several extra functions (e.g. install/remove MFS) and protecting index control fields in dict items. Also adding %POSTPROCESS% which is just like %PROCESS% but happens after record copying. Thus one can copy a new dict item and then index it, etc., etc. There are also some problems of detail is using the same update for several sites with different @DBIDs, data locations, etc. - hence tweaks so that copyfile works on default or Global source file and can target either specific location or same location as named attached file.

We've also had a lot of fun and mystery with the DBT files when sending updates to users. Also we don't always want to use DBT - e.g. one of our users has three separate similar databases separately configured for each of their clients. At logon they are asked to select which and can swap whenever they want at the touch of a button. All done by Attach & Detach where DBT would get in the way.

Hence as a matter of policy we now use DBT only for main system files and do the rest with an Attach at logon. The logon time difference, if any, is imperceptible and it's all a lot lot safer.

Also so as to be able to do what we want and to be able to make mods quickly, we've now been running our own T-List report writer for several years. It's great to have an idea (or a user request) and be able to implement it immediately!

I think RTI's policy gives us the great combination of a great RDBMS which one can just use "out of the box" or adjust a bit if necesary for one's own particular purposes. Of course the same could (and still can) be said for ARev.

Hope these ideas might be of some interest, if not use.

Richard Guise

Tornado PS Ltd.

View this thread on the forum...