Good in theory, but has not worked for me in practice. Perhaps I need to retest, but if my failing memory serves, a new directory install results in dropped redirection macros.
Now for the problem at hand –
The equates are from 1997 and then HTML 1.2 standards. What rightly seems to give a v13788 compile error, never did in any version since the file was created. Consider these 2 equates:
eTitle EQUATE(‘<< TITLE><13,10’)
eTitle EQUATE(‘<< TITLE><13,10>’)
With the final > missing, there is now an error. Obviously copied, lines in a couple of file SECTIONs either contained or did not contain the character. (a space has again been added for display here)
Yes you are indeed correct. In the future, I will not attempt to add information when more important obligations limit my testing time. There were indeed 17 lines & 17 Invalid string… errors. I should have more clearly stated - nothing more I can consider at this time.
There is clearly a missing > from the end of this line.
But the second line is correct, << should be doubled, but > is not doubled.
Perhaps you are not setting up the versions using the MACS system correctly? I have (currently) 24 Clarion installs with various combinations of Clarion, and Accessories for testing, and I’ve not noticed a problem.
I understand you are under time pressure, but you might find it easier to switch from one build to another if switching / testing is as easy as selecting the version from a menu item.
Agreed. The difference with v13788 is that it now gives a compile error.
Was surprised also to find that a missing comma in COMPILE & OMIT gives an error in this release. This came up in a long used third party product you likely know. No clue why now.
Probably worthy of a discussion under a separate topic, but I will ask if any of the 24 installs involve changes to the shipping classes, templates, or accessories. While I doubt you’ve ever needed to customize Capesoft products , there are other providers to consider.
How best to accommodate all product version updates is a topic for everyone.
Some have tweaks to the Clarion classes and templates. Especially small things like PRIVATE attributes, extra embed points and so on.
The accessories can be quite varied. So I’ll have some with say NetTalk 10, some with NetTalk 11, some with 12, and some with my current “in progress” work. I’ve also got splits over different clarion versions, from 8 through 11.1. Mostly though I’m in 11.1, 11.0 and 8 (for shipping examples.)
A good example. Your suggested new version process implies to me these get copied to the new version folder and then overwritten by the new install. What then?
I’m typically running the latest install as the IDE. It remembers everything from the previous IDE, I just add the now-most-recent version as a “version”. That’s all described in this thread: Multiple Active Clarion Systems (MACS)
Once that’s done (which take maybe a minute to set up) I can then take apps and compile in this build, or switch to that build and so on. So I can test for changes, check if some behaviour is new, or was there before, and so on.
All this works for Clarion itself, but also for 3rd party stuff - hence the NT10, NT11 and NT12 folders.
Perhaps I am dense, but that has never worked for me without time consuming class & template file comparisons upon a new release. Fortunately, once adopted, I haven’t any reason to keep >1 or 24 versions.
after considering this I have now come to the conclusion that the change in the latest version is a GOOD thing - I hope it is not put back to how it was before.
consider:
‘xyz<13,10>’
this is a 5 byte string
in contrast:
‘xyz<13,10’
is a 9 byte string.
(note the <<TITLE> was a red herring hence I am just using xyz)
Doug meant to have cr/lf (2 characters) on the end but instead had 6 characters on the end : <13,10
By the sound of it Doug’s bug had gone undetected for years over many versions of Clarion and now this new version has highlighted it so it can be fixed.
If Doug had actually wanted those 6 bytes on the end he would now have to double up the < so that it was <<13,10
anyway Doug should be grateful that his long standing bug has been found by an improved compiler.
so my take is to either leave it as it is now in 13788, or perhaps make it more stringent so that it matches the documentation and all < in a string need to be doubled up (not just those before a digit).
so there’s a different (opposing) take to “fix the regression”.
Not sure about grateful, but very surprised that an obvious error went undiscovered so long. As for use in my App, it never really had an impact but relates to early HTML use in the 1990’s. If I had not received errors noting <<, I do not believe I would have even read this thread.
Essentially,
OMIT(’!EndOmit’ aBooleanValue) << no comma between parameters
Easy to see how this would be missed if the compiler did not give an error. Definitely no shame to have it. I know it is used in many 3rd parties for different Clarion versions (especially pre/post v6). Again, very surprised to see it when I recompiled a 36 DLL solution w/ 13788. I have used the library code for well over 10 years.
, there are other providers to consider.