1. Phix : string type -> type check failure
- Posted by ChrisB (moderator) Dec 01, 2019
- 1092 views
- Last edited Dec 02, 2019
Hi Pete
Getting a fully qualified pathname/filename from a file dialogue, and processing to just get the filename
CSV_current = FileDlg(Open, "", "CSV|*.csv") if length(CSV_current) > 0 then SetText(FramedText03, get_file_name(CSV_current)) end if
Gives
C:\Phix\builtins\pfile.e:49 in function get_file_name() type check failure, path is {67,58,92,80,104,105,120,92,80,114,111,103,1.. path[1..18] = {67'C',58':',92'\',80'P',104'h',105'i',120'x',92'\',80'P',114'r',111'o',103'g',114'r',97'a',109'm',115's',92'\',69'E'} path[19..37] = {85'U',87'W',105'i',110'n',71'G',85'U',73'I',92'\',69'E',87'W',71'G',45'-',68'D',101'e',115's',105'i',103'g',110'n',101'e'} path[38..55] = {114'r',92'\',80'P',114'r',111'o',106'j',101'e',99'c',116't',115's',92'\',86'V',101'e',116't',65'A',110'n',97'a',108'l'} path[56..73] = {121'y',115's',101'e',114'r',92'\',65'A',108'l',108'l',87'W',111'o',114'r',107'k',45'-',83'S',101'e',112'p',116't',45'-'} path[74..80] = {78'N',111'o',118'v',46'.',99'c',115's',118'v'}
in function get_file_name
global function get_file_name(string path) if not finit then initf() end if path = get_proper_path(path) path = path[rfind(SLASH,path)+1..$] return path end function
produces the error
and changing the string to a sequence,
global function get_file_name(sequence path) if not finit then initf() end if path = get_proper_path(path) path = path[rfind(SLASH,path)+1..$] return path end function
functions as expected, no error
Cheers
Chris
2. Re: Phix : string type -> type check failure
- Posted by petelomax Dec 02, 2019
- 1021 views
What exactly is FileDlg()? That's the thing that should be fixed, not get_file_name().
I have had a fair few of these in Edita/Edix, and if you don't stamp on them at source you end up chasing your own tail, and making a complete mockery of having a string type in the first place.
A routine that returns a qword sequence when it should/may as well return a string is wasting 7 out of every 8 bytes, or 87.5% of memory (on 64-bit, obviously a mere 75% on 32-bit).
Besides, who wants to see that mess in their ex.err when it could have
path = `C:\Phix\Programs\EUWinGUI\EWG-Designer\Projects\VetAnalyser\AllWork-Sept-Nov.csv`
EDIT: My C:\Program Files (x86)\Phix\demo\tinEWGdemo\tinewg.ew/FileDlg() almost has this, I have added the commented-out file = {} to indicate the sort of thing I was looking for
if file=0 then file = "" else index = 0 -- file = {} file = "" while peek(szPointer_file+index)>0 do file = file&peek(szPointer_file+index) index += 1 end while end if
3. Re: Phix : string type -> type check failure
- Posted by ChrisB (moderator) Dec 03, 2019
- 989 views
Thanks for reformatting the message, a lot clearer to read that way, laziness on my part.
FileDlg is from EuWinGui, a 32 bit only library. It returns a string containing the path - it does not specify what sort of string is returned. Why would I care?
Also, why would I care about how many bytes were wasted in a small quick and dirty utility. Surely this is something the parser/compiler should worry about, and do it quietly.
Also, and I'm sure this is clear to you, and I haven't had a lot of time to look at yet, but what is the difference between a dword-sequence and a string? (I know you said qword - the docs seem to indicate this is a 32/64 bit difference.
Cheers
Chris
Edit : I've just read this and it looks a bit abrupt. Not my intention, merely abstracting a Joe programmer. Cheers, Chris
4. Re: Phix : string type -> type check failure
- Posted by petelomax Dec 03, 2019
- 993 views
what is the difference between a dword-sequence and a string?
One typechecks and the other doesn't
Maybe the last bit of code below will help, but if the glossary in the manual (contains both those terms) does not make it clear, not sure what else I can say...
Edit : I've just read this and it looks a bit abrupt. Not my intention, merely abstracting a Joe programmer. Cheers, Chris
No worries. Not personal, just heated and lively debate. Got it.
My problem is change get_file_name() and there are two dozen others that should follow suit.
- however I genuinely value those kind of typechecks, though maybe I could "if not string(s) then s := eight_bit_string(s) end if" times 24...
Another problem is that EuWinGUI is (annoyingly) closed source and therefore difficult to support properly on Phix (and 32-bit-Windows only).
You know that above it actually returned "{67,58,92,80,104,105,120,92,80,114,111,103,1.. ", literally that exact specific string...? (Ugh/Yeuk)
Anyway, I have a suggestion. Change EuWinGUI.ew
global function FileDlg(atom dlgtype, sequence filename, sequence filter) -- return v3_c_func(filedlg,{dlgtype,filename,filter}) return v3_c_funcs(filedlg,{dlgtype,filename,filter}) end function
While you are there, GetText() can take the same treatment.
Then, add that/this new function into euconvertinc.e:
public function v3_c_funcs(integer func, sequence args) sequence q = v3_c_func(func, args) integer l = length(q) string res = repeat(' ',l) for i=1 to l do res[i] = q[i] end for return res end function
EDIT: Just after posting, I realised there may be a problem in value(). I haven't tried changing this, but in get.e/Get(), line 298 there is indeed:
-- process a sequence s = {}
Now if s started off as "" instead, it might return a string, and avoid all this mess...
5. Re: Phix : string type -> type check failure
- Posted by ChrisB (moderator) Dec 04, 2019
- 950 views
Yup, reverted Phix, and made those changes in EuWinGui, and all working now.
Although, as a point of argument, having a string 'type' kind of takes away the atom/object/sequence simplicity argument.
Cheers
Chris