Hi all,


V 2.4.6.0 is online - added overlay icons in Project Explorer indicating ANSI or Unicode encoding. Added a bookmarks window listing bookmarks of open files. See help file (Bookmarks) for more information.


JK

Currently FB converts wide string to ANSI for all file/path related functions. That is, you can only use wide strings representing ANSI strings, "real" unicode strings (e.g Russian characters) fail. I replaced all ANSI entry points with wide string entry points in Windows. The conversion i...

Jeff, i need your help. Please read the comments for PR #178 and #180. Supplying only wide string versions in the RTL for Windows would make things easier, but it would break direct compatibility for Win 95, 98 and ME. Executables for these OSs can still run, but would need changes then. How should ...

Thanks for the clarification! If i interpret this correctly, this means, that in Linux i already can have a file name with e.g. Russian characters ("йцуке.ячс"). So for Linux no change in the compiler is required - is this correct? In other words, the Unicode file name problem only exists ...

There is a PR for the new array features and a PR for USTRING as a default dynamic wide string type based on the recent EXTENDS WSTRING development - time for a next step: (dynamic) Unicode strings in file handling functions. Currently you can pass a WSTRING to e.g OPEN and the file will be opened, ...

For all interested in testing the new fork is here. PR # 173 is ready for review.


JK

@Jeff i need a name for my include file, a logical name would be "array.bi". But then there already is "array.bi" in \fbc-int. Two files with the same name in different directories - not a very good idea i think, this is bound to lead to confusion. So either your "array.bi&q...

I will delete this fork of fbc, so the link provided in previous posts will no longer be valid.

Forked from the latest fbc version i will rebuild, what i have, separated in smaller commits for preparing a PR.


JK

@Jeff, thanks for pushing thing forward! Sorry, I just haven't had time to go in to it deeper. I like that you attack problems head on to arrive at a solution, and I understand what you are going for as an end result. My initial reaction to the fbc code changes is that I'd like to look a little deep...

@Jeff, thanks, i will wait for the merge and i will try to break it into digestable commits. BTW did you notice my reply to your comments on #158 ? Having a solution for this problem is not a requirement, but it would make my additions more complete. @MrSwiss There will be a method of detecting dyna...

@Jeff,

should i start preparing a pull request for my array features with what we have now, or should i wait for you to merge #169 ?


JK

I made TYPEOF() work in regular code too in my array additions. It returns the the name of a variable´s type as an uppercase string for all variables (not only arrays). This may seem not to be the most elegant solution, but it allows to distinguish between different UDTs, because the name as given i...

Do whatever is necessary to push things forward. One thought about presenting the array descriptor: - If you choose to make the array descriptor available by reference (return a pointer to the array descriptor), then this includes the possibility to modify the descriptor members by the user. I think...

You could even make it one single (2 bit) flag, because the "states" are mutual exclusive: 0 = dynamic 1 = fixed dimensions, variable number of elements 2 = fixed size, fixed number of elements 3 = attached (only possible for former dynamic, so an attached array, which is reset, must becom...

Or treat this kind of hybrid declaration (fixed number of dimensions, but variable number of elements) as a third variation of arrays (fix-len, var-len, fix-dim (?)) and reserve a flag bit for it.


JK