issue-#168 improvements in DevLinkChk

[Josef Templ]

While checking for inconsistent links in 1.7.1 beta, I noticed several shortcomings (mostly bugs) in DevLinkChk.
Fixing these bugs yields several inconsistent links that were undetected previously. See below.

I have created https://redmine.blackboxframework.org/issues/168 for that.
A proposal for a fix has been committed.
The diffs are here https://redmine.blackboxframework.org/p ... 732452be3b.

The main difference is that a parser similar and consistent with StdInterpreter is now used.
This requires more coding but allows for checking multiple commands in a link.
It also provides for consistency with the checks done in StdInterpreter (Dialog.Call).
(Theoretically, it would be possible to reuse the parser from StdInterpreter but only if substantial parts
are exported and for that StdInterpreter would have to be reorganized substantially. I did not want to go as far as that.)

Since this issue showed up as part of the release process of 1.7.1 I hope that
we can agree to add this to 1.7.1 beta.

The list of reported problems is this:

Code: Select all

Dev
	Docu
		Analyzer.odc
			StdLinks.ShowTarget('Contact Information')
		User-Man.odc
			StdCmds.OpenBrowser('Docu/Tut-3.odc', 'BlackBox Design Practices');StdLinks.ShowTarget('subsystems')
			StdCmds.OpenBrowser('Dev/Docu/Packer', 'DevPacker docu'
System
	Docu
		User-Man.odc
			StdCmds.OpenBrowser('Docu/Tut-3.odc', 'BlackBox Design Practices');StdLinks.ShowTarget('subsystems')

- Josef

[Zinn]

I run the new version and notice in the report
StdCmds.OpenBrowser('Dev/Docu/Packer', 'DevPacker docu'
is missing the bracket ) at the end of line,
but this line should not occur, because this link in the User-Man.odc is working.
It is a big improvement. Thank you.
- Helmut

[Josef Templ]

I run the new version and notice in the report
StdCmds.OpenBrowser('Dev/Docu/Packer', 'DevPacker docu'
is missing the bracket ) at the end of line,
but this line should not occur, because this link in the User-Man.odc is working.
It is a big improvement. Thank you.
- Helmut

It only works because in StdInterpreter this special kind of syntax error is ignored (accidentally?, I don't know).
It is an error and the checker should report it, I think. It should also be fixed, by the way.

- Josef

[Zinn]

OK, now I understand. The syntax is wrong, but the link works anyway. So it is right to report this link.
- Helmut

[Robert]

I have several times noticed that incorrect links sometimes work.

Should the interpreter be less accepting of errors, or is this behaviour actually beneficial?

[Josef Templ]

I have several times noticed that incorrect links sometimes work.

Should the interpreter be less accepting of errors, or is this behaviour actually beneficial?

Actually it reports an error with Dialog.ShowMsg.
"Link Call Failed ) expected"
but then it continues with executing the command. So it is actually contradictory.

The fix in StdInterpreter would be simple:

Code: Select all

					CallProc(left, right)

changed to

Code: Select all

					IF res = 0 THEN CallProc(left, right) END

- Josef

[Robert]

The fix in StdInterpreter would be simple: ...

I don't think we need this fix, but don't feel strongly about it. If anyone else wanted it I would support that.

[Josef Templ]

I would prefer to fix it.
Since it reports an error it should also treat it as an error.

- Josef

[Josef Templ]

In addition it is very tempting to lift a limitation in StdInterpreter:
It does not support BOOLEAN parameters.

I had situations several times in my apps where I needed to define a BOOLEAN parameter as INTEGER or string in order to
work around this limitation. When looking into the details of StdInterpreter it turned out that this
would be very straight forward to support.

- Josef

[Robert]

In addition it is very tempting to lift a limitation in StdInterpreter:
It does not support BOOLEAN parameters.

Guards (& Notifiers) have the two forms (as seen in the property inspector) "MyModule.Guard" & "MyModule.Guard(<INTEGER>)".
Would this suggestion open the door to also supporting the form "MyModule.Guard(<BOOLEAN>)"?
I think that would also be a very convenient additional feature.

I also think that the current documentation is inadequate regarding the different forms that Guards & Notifiers can take. But we are far off topic "issue-#168 by now!