File name verfication

[NasaCow]

Code: (Select All)

    ISVALID` = TRUE
    FOR LoopCounter = 1 TO LEN(FileName)
        FOR LoopCounter1 = 1 TO NumberOfVaildCharacters
            IF FileNameParts(LoopCounter) <> Legal(LoopCounter1) THEN ISVALID` = FALSE: EXIT FUNCTION
        NEXT LoopCounter1
    NEXT LoopCounter

Set the function return value and leave straight away, no need to check it and no need to "set the trap" at each character in the "FileName" to check. This was coded also for more consistency with the function body code that appears before this demonstration.

Also I suggest using a "FOR... NEXT" loop to initialize most of the Legal() array. Because you will have to include uppercase and lowercase letters to check on Linux and MacOS. Filenames on Unix and Unix-like operating systems are case sensitive.

I have to set the trap because in this case EVERY filename will faii. For example A <> B and thus you will exit out through the trap. If I check for illegal characters, it would work (and that's what my first try was) but then I have to think of everything. I decided to whitelist, instead of blacklisting. With whitelisting, I need to set a trap to check assuming it is a failed charater and switch to true when I find a whitelisted character..... Unless I am missing something else   

And I am not as familiar with MacOS or Unix, but wouldn't the code still find it is vaild since I am converting everything to uppercase with UCASE$? I am not checking if a file exists, but if a given filename can be written to the system? _FILEEXISTS already is a great tool for that job. If not, I will be happy to add lower case to the search field.
 

If I can find my code then I'll send it. I was dealing with files with Korean, Chinese, and Japanese characters in the filename with no issues at all by just replicating FileExists but with wide string usage as well as using my AnsiToUnicode wrappers for converting between CP437 and UTF8 and vice-versa. The only issue you might have would be trying to display the name of the chosen file. I think you would also need to use the wide version of GetOpenFileName like I did. I was even able to replicate the drag and drop functions in QB64 as wide versions. I have no problem dropping any files with foreign characters in them.

I was wondering if you knew how to read input in Chinese from the keyboard, that would be very useful for me. I haven't been able to figure anything out. Displaying Chinese charaters is straight enough with QPrint (Uprint) with the proper font file that supports unicode. But I haven't been able to read anything from the keyboard... yet!

[SpriggsySpriggs]

Well, I wasn't reading Chinese keyboard input. I was reading files returned from dialogs. I imagine if I wrote a custom input routine, it would work. You'd just need to be able to display the characters you're taking in so you know what you're typing. Could be a fun challenge.

[SMcNeill]

I was wondering if you knew how to read input in Chinese from the keyboard, that would be very useful for me. I haven't been able to figure anything out. Displaying Chinese charaters is straight enough with QPrint (Uprint) with the proper font file that supports unicode. But I haven't been able to read anything from the keyboard... yet!

https://qb64phoenix.com/forum/showthread.php?tid=21 -- If you're using Windows, you can use my Keyhit library to read a chinese keyboard. You'd just have to configure it to map to the proper keys on the keyboard. I've never had any Chinese keyboard (and certainly don't know the language any at all), so I've never had a chance to work up a character mapping to any keyboard with their characters on it. In the library is mappings to European keyboards, German, Italian, and US Standard keyboards, so you could probably use those as a roadmap to help you set it to whatever you need it to map to.

[NasaCow]

Well, I wasn't reading Chinese keyboard input. I was reading files returned from dialogs. I imagine if I wrote a custom input routine, it would work. You'd just need to be able to display the characters you're taking in so you know what you're typing. Could be a fun challenge.

I was wondering if you knew how to read input in Chinese from the keyboard, that would be very useful for me. I haven't been able to figure anything out. Displaying Chinese charaters is straight enough with QPrint (Uprint) with the proper font file that supports unicode. But I haven't been able to read anything from the keyboard... yet!

https://qb64phoenix.com/forum/showthread.php?tid=21 -- If you're using Windows, you can use my Keyhit library to read a chinese keyboard.  You'd just have to configure it to map to the proper keys on the keyboard.  I've never had any Chinese keyboard (and certainly don't know the language any at all), so I've never had a chance to work up a character mapping to any keyboard with their characters on it.  In the library is mappings to European keyboards, German, Italian, and US Standard keyboards, so you could probably use those as a roadmap to help you set it to whatever you need it to map to. 

This is beyond my technical knowledge. All computers will use the standard physical layout (US based I assume?) and there is a software input called input method engine (IME) that (I assume) translates the particular code to unicode so the computer knows which character to display for example when I am typing 我能打中文。it looks like this:




In a dos program in windows it looks like this:






Which means I can type Chinese. I know hardcoding into the IDE is out (since doesn't have a standard page?) but if the needed statements to print come from a text file and used with qprint (or uprint) then just comes down to taking a few extra steps to print text. (Time to make a cprint? hehe)

So, I believe is after a extended unicode (once again, I believe) is produced by the IME (see above as an example) is taken in by input (how would you even make a custom input command to start with? Do you read a keyboard buffer? Do I need all inputs be dumped to a file and then printed to the screen? Not sure what would work...) and if the extended-unicode (assuming I am right) can be preserved then there is nothing stopping a programmer to reprint it to the screen to display it. I would mind doing the grunt of programming if I understood it from a conceptual idea. I justs need to learn how the typing interface works with the OS or the program or.... Just spit balling here. Might just have to try and see what is produced!

[SpriggsySpriggs]

I'd have to do some digging into this. I'm not sure how long it will take me to make headway but the first thing I'll do is revisit my Win32 Video Player as it handles files with any and all characters. I can grab some of that stuff and then see about either using Win32 or C to make me an input routine that takes in and also displays Asian characters. The only caveat (which may or may not be a dealbreaker for you) is that I'd have to make the input side work in the console side but then we can switch to a graphical display afterwards. Or, we can make a Win32 GUI which will then be able to handle all of that. Using a built-in QB64 window ain't going to work for us on this one.