Whishlist #1348 -> ArraySortType, etc..

[Borje Hagsten]

I have an old DLL from Crescent Software here, QPRO200.DLL, also
known as Quickpak pro. It has some neat and very useful routines,
well worth including in a future version of PB:

ArraySortTyp, almost same as the existing Array Sort routines,
but for user-declared types instead. One just have to tell the
routine what member of the type to sort by. Extremely fast and
very useful. ArrayScanTyp, ..InsertTyp, ..DeleteTyp would also
be handy to have.. :-)

DCount/FCount, counts all directories/files under a given path.
Good to use with the next two routines:

ReadDir/ReadFile, reads all directories/files under a given
path into an array in one take. There's also ReadDirT/ReadfileT
which reads it into a type declared array. Probably written in
assembler = very fast and extremely nice to use for recursive
searches, etc.

There are many other useful routines in this file too, but the
two above are the ones I have had most use for, so they may be
worth adding to the whish-list.

[E B Knoppert]

I do that already.

You need to use an offset and make the request element a string
So, if your searching for a hWnd use MKL$ to search for.

Like this:
ARRAY SCAN MyArray(), From 1 TO 4, = MKL$( hWnd ), TO I

Set the from parameters to the correct offset to sort or scan for..


------------------

[Peter Stephensen]

This works (dont ask my why )

Regards
Peter

#COMPILE EXE
 
TYPE TESTTYPE
    txt AS STRING*128
    element1 AS LONG
    element2 AS LONG
    element3 AS LONG
END TYPE
 
FUNCTION PBMAIN
 
    DIM x(3) AS TESTTYPE
 
    x(0).txt = "bbb" : x(0).element3 = 1
    x(1).txt = "ccc" : x(1).element3 = 2
    x(2).txt = "aaa" : x(2).element3 = 3
    x(3).txt = "ddd" : x(3).element3 = 4
 
    ARRAY SORT x()
 
    MSGBOX TRIM$(x(0).txt) & $CR & STR$(x(0).element3)
    MSGBOX TRIM$(x(1).txt) & $CR & STR$(x(1).element3)
    MSGBOX TRIM$(x(2).txt) & $CR & STR$(x(2).element3)
    MSGBOX TRIM$(x(3).txt) & $CR & STR$(x(3).element3)
 
END FUNCTION

------------------

[Borje Hagsten]

Thank you, both E. B. and Steve - very interesting, indeed.

Seems like we also can sort by any member in a type declared array.
The following sorts the array in your example Steve, by element3
(128 + 4 + 4 = 136):

    x(0).txt = "bbb" : x(0).element3 = 4
    x(1).txt = "ccc" : x(1).element3 = 3
    x(2).txt = "aaa" : x(2).element3 = 2
    x(3).txt = "ddd" : x(3).element3 = 1

    ARRAY SORT x(), FROM 136 TO 140

------------------


[This message has been edited by Borje Hagsten (edited June 03, 2000).]

[Michael Mattias]

Seems like we also can sort by any member in a type declared array.
The following sorts the array in your example Steve, by element3
(128 + 4 + 4 = 136):

When ARRAY SORT FROM X to Y is used on a string or UDT array, the characters in the FROM ..TO sort range are treated as strings. The only reason your example works is because all the numeric values you have used are in the range 1-255 and do not cross a byte boundary.

If you want to use ARRAY SORT on numeric values, you need to convert those values to some format which, when sorted as characters, preserves the sort order.

Unfortunately, no PB datatype works.

Fortunately, there *is* a format which works, called String Signed Binary, or SSB. Do a 'search' in the source code forum for "SSB" and/or "String Signed Binary" and you will find some PB functions to convert SSB to and from long integers.

MCM
(inventor of SSB data types)

[Borje Hagsten]

Byte boundary? Nah, tried the following, using CUX for one member
and it still works fine (floating points, large numbers:

COMPILE EXE
 
TYPE TESTTYPE
    txt AS STRING*128
    element1 AS LONG
    element2 AS CUX
    element3 AS LONG
END TYPE
 
FUNCTION PBMAIN
 
    DIM x(300 to 303) AS TESTTYPE
 
    x(300).txt = "bbb" : x(300).element2 = 99999999.04
    x(301).txt = "ccc" : x(301).element2 = 99999999.03
    x(302).txt = "aaa" : x(302).element2 = 99999999.02
    x(303).txt = "ddd" : x(303).element2 = 99999999.01
 
    ARRAY SORT x(300), FROM 132 TO 133
 
    MSGBOX TRIM$(x(300).txt) & " " & STR$(x(300).element2) & $CR & _
           TRIM$(x(301).txt) & " " & STR$(x(301).element2) & $CR & _
           TRIM$(x(302).txt) & " " & STR$(x(302).element2) & $CR & _
           TRIM$(x(303).txt) & " " & STR$(x(303).element2)
 
END FUNCTION

Seems like we only have to point to the member we want to sort
by (FROM 132 TO 133)

I can't say I understand why, but it works - maybe someone with
more inside knowledge can explain why? Also, in case it's "legal"
to use the Array routines like this, I think it's worth including
this information in the helpfile.


------------------


[This message has been edited by Borje Hagsten (edited June 03, 2000).]

[Michael Mattias]

Byte boundary? Nah, tried the following, using CUX for one member
and it still works fine (floating points, large numbers:

Well, I tried that example, and no, sorting does not work. Try some negative numbers, AND get your numbers in the ranges crossing 25500 (CUX) or 2550000 (CUR).

I thought I'd look up the CUR and CUX data types and do a little analysis and testing. While the PB/DLL 6.00 help file says,

" Since currency numbers store the actual decimal digits as part of the number,"

..it turns out that the help file is in error!

It seems CUR and CUX variables are stored as Quad Integers, CUR multiplied by 10000 and CUX multipled by 100. Negative CUR and CUX numbers are stored as quads, too, in twos-complement form. (This means the "actual decimal digits" are NOT stored!).

Sorting? Well, unless PB adds a features to the compiler like:

ARRAY SORT UDTARRAY(), FROM 10 to 17 AS CUR ....

..you are going to need to reformat numeric data within UDTs if those values are to be used as sort keys.

That or use a separate array as a key to sort with a TAGARRAY of the UDT array. (Or beg me to migrate my array sorter - which works like this -to a Windows DLL).

MCM

[Borje Hagsten]

Yes, I see the problems now. Back to the original whish - sure
would be handy to have built-in Array functions for UDT's..


------------------