If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

@Netech:
There is is a very very very nasty bug in the latest version(s) of LCode!
I can confirm this bug in the version 1.0.9.13 and I can confirm that version 1.0.9.6 is without this bug. Rest of the versions I haven't tried.

I tried to fix a special combination of single Bit and different number of multibyte definitions.
But then there is just another untested, special combination
I have not tested all combinations now, I will try and make a configuration to test many/all combinations.

LCode updated in #1.
{1.0.9.14}
{Bug again with mixed menus and single bit setting}

NEtech: Hi.
I'm deeply traumatized and I had to re-load the new .exe file a few times to confirm my initial incredulity.

With the preface that I intend absolutely no offense and with an acknowledgment that I am one of the biggest fans of LCode - I must advise that your new software has shaken the very foundations of my "numbers world".

It is with much trepidation that I tentatively suggest that the latest incarnation of LCode appears to have misplaced Byte 0. I emphasize the term "appear" because I half suspect that I am misunderstanding something. However, the fundamentals of the hexadecimal numbering system hasn't changed since well before I was a bespeckled geeky kid trying to understand why the human brain should be inflicted with a base 16 numbering system (and that was a very, very long time ago)!

It was bad enuff when the ODIS designers made the same error, but the sanctuary of VCDS's adherence to the correct nomenclature provided a satisfying refuge for those of us that expect mathematical normalcy in devices that use hexadecimal numbers!

Yes, ODIS is also used by lots of VCDS folk - but I suspect even more VCDS users have never been aware of the ODIS numbering error. And in any event, I'm not sure that this is a sufficient reason for violating one of the basic tenets of the civilized world (OK, perhaps a tad over-the-top)!

As a long time user of your work, my plea is - please don't allow the tail to wag the dog!!

Don

PS: if you retain a non-Byte 0 hexadecimal numbering protocol - will you do the same for the Binary numbering system - Shirley not?

Sorry I don't quite understand what you are telling, asking.
Is this wrong:

Now starting at Byte 0.

Here is a short text (from earlier), of the test version.

Here are some different information about this first test (Alpha) version.

If there is long or short coding in Windows clipboard, and LCode is started (not from VCDS), the coding is inserted.
When closing LCode, the current coding is copied into Windows clipboard, if not wanted then define this in ini file: Copy-Clip=0 (Std.), if wanted: Copy-Clip=1

There is a new Spin button where arrows from keyboard can be used, Up increase Byte value!
Also mouse (or touch) can be used to "walk" through the Bytes, with spin buttons.

It is possible to drag and drop LBL or XPL files to LCode Window.

Different languages can be translated easier using *.PO files, with for example POedit.
The language files are inside the exe file, there are only one LCode exe file and a ini (configuration file).
Languages can be changed as you wish, the language that is chosen before quitting, is defined in ini file and used next time.

Label files could be saved in UTF8, so it could be showed correct in all languages, but that is not possible, for text that VCDS shows, it must be ANSI text.
But it would be possible to make a sign in the label file to let LCode show text in UTF, if the text should only be showed in LCode.
But there would probably not be so many files.
Now LCode will show label text as UTF if definition in ini file is: UTF-file=1
So for now it would always be UTF-file=0 (Std.)

If Coding Byte length is above 52 Byte, Window is maximized in width and placed at the bottom of the screen.