Yes, I certainly am creating a character file (though not necessarily printable characters), but that does not mean that being able to specify low-values is not a useful facility in dealing with sequenced files in matching etc. In this it corresponds to High-values for end of file or end of procedure facilities, instead of say, checking for end of file or end of string every time.

In the same program I am in fact using high values (X"FF") by entering "[alt][255]" as someone recently pointed out helpfully. This alt-character facility seems to work for everything but X"00", which I then had intended to use, but have found the editor unable to handle.

Now, there still are options I can manage, such as using a hex editor on my Basic source file, but that seems an eccentric measure to have recourse to in such a powerful facility as QB64. I thought that the developers would like to know of the bug. If not, OK, I'll manage. Thanks anyway.

If you have Windows and don't want to worry about Linux or Mac users (ie doing a cross platform app) there are easier ways.

.....

The majority of this code is spent with selecting an item from an array, in this case an array of directories or of files when you press f. You could use simpler techniques. LoadDirs and LoadFiles are main routines for getting folders and files from current directory if I recall correctly.

Forgive my blundering; I still haven't mastered the facilities in this forum. 😳 Everything in time 😉

Thanks Petr and Codeguy. I'll have to go into this to see what best applies to my requirements.

Please see the original dumb question for the background.

I am converting a very old MS VB sort, so old that I had forgotten how I had written it, and had assumed that the subroutine statement at the head was part of my design at the time. However, it only later came back to me that all the apps that VB creates are in the form of Private SUBs.  Then I had problems with Const statements for unprintable characters, till some of our helpful spirits in the forum solved them for me. (Thanks again folks!)

But I was going nuts with incomprehensible diagnostics (one at a time!) about all the constants being taken as if they were new undefined variables.

Only after the penny dropped did I realise that the SUB statement was a VB contribution, and not relevant to the program, and was messing up the contexts. When I commented out the SUB statement the problem went away. I don't know whether my problem is unusual or not, but in case anyone else works on converting VB programs, and gets funny diagnostics, it might be something to think about.

Wish me luck in achieving a working program, now that the diagnostics are gone.

How do I instead define a variable string with an 8-byte string of ASCII-255 characters? I have tried several versions of &HFF expressions without success..

User$ = STRING$(8, CHR$(255))

---

DIM HiVal$ AS STRING tosses an error for redundancy.  Either use:

DIM HiVal$

Or use:

DIM HiVal AS STRING

There's no need to use $ with AS STRING.   ;)

Thanks SMcNeill; that made sense, and was the original form that I had used, but the pitch was queered by other problems as yet unsorted. However your putting it so explicitly solved that one at least. Your patient reply much appreciated. More in my reply to moises1953 anon.

Hi anyone,

I am no programmer anymore, using QB64 just as a lazy convenience tool, but I found a need for an old sort I wrote for another purpose more than 20 years ago in MS VB and am in the process of trying to translate it instead of rewriting it.

I expected to suffer of course, but ...

Now, most of it is not causing obvious drama, though more keeps surfacing, but as an old assembly language programmer, I like to access the data in native format, and the original program used the concept of high values, strings of bytes with all one-bits, and in particular I was trying to create 8-byte strings of high values or referring to them as a CONST "********"

When that did not work though Const LowVal = "" DID work (apparently) I tried to create the string with DIM pluss assignment, and all went pear-shaped.

* How do I define a constant of a string of length of 8 bytes with all 1-bits. (Defining an empty string Const as "" looks happy).
* How do I instead define a variable string with an 8-byte string of ASCII-255 characters? I have tried several versions of &HFF expressions without success
* I was using option explicit in VB and kept it in QB64 (I like that option) and Dim HiVal as STRING I get all sorts of pain like getting diagnostics about missing commas (well, there WAS no comma, sure, but I could not find any reference to which comma with what meaning or where. (eg DIM HiVal$ AS STRING    gets me a missing comma. Dim HiVals as string gets me variable not defined. etc)
* If I finally quiet that diagnostic then I get more diagnostics in which it fails to recognise variables as string variables in spite of having DIMmed *everything*
* If I remove option explicit, then  LineRead = LowVal (lowval is COnst ="", and Lineread is DIMmed as string)  gets me illegal string-number conversion.

*Just wistfully, If there is one feature I would LOVE, it would be to be able to redefine data values so that say, I could create an _UNSIGNED _Integer64 variable, and treat it as say, a string of 64 bit values or an 8-byte string. (Yes, I know, but if things go wrong, I would have no one else to blame. I yearn for the old macro Assembler days (snifff...)

Now, if I can get this all fixed up, then I was going to upload a suitable version of the sort as a utility in thanks for the pleasure QB64, but at the moment I am treading water and going down. Anyone who would like to see the code is welcome, but I did not want to display 200+ lines just here without first having chewed it over first.

Please help, anyone with sufficient patience.
Thanks apologetically,
Jon

Replying (partly) to my own question.

I had a sudden satori. I removed the Deflng statement, and inserted a _Define A-Z _Unsigned _integer64 statement at the top.

That seems to have worked magic on automatic intermediate values, and suddenly my test code at least seems to work correctly.

It seems a rather brutal solution, but not impossible.

Is there any policy concerning intermediate values that needs re-thinking? If not, where do I find a statement on the principles QB64 adheres to?

Thanks for attention so far.