RunDialog Options need specific formatting?

Panorama X
1

I would have preferred to put this into BitBucket but I think that option is no more.

I’m not knowing if I’ve missed a rule that states how Options are supposed to be formatted but either this is a minor bug or a rule I’ve yet to have learned.

The following does not work but instead presents an error.

RunDialog {Form= "Duplicate Patient?" Height=120 Width=400}

RunDialog Form Name Error
RunDialog Form Name Error262×201 21 KB

What eliminates that error is removing the space following the option ‘Form=’.

RunDialog {Form="Duplicate Patient?" Height=120 Width=400}

And should it say ‘OPENDIALOG’?

2

rundialog is a custom statement (in the _DialogAlertLib library) which itself contains one opendialog statement:

    opendialog tagparameter(parameter(1),"form=",1),
        "DATABASE",dlgFile,
            "CLONE",dlgClone,
            "TITLE",dlgName,
            "CLOSEABLE",dlgCloseWindowButton,
            "RESIZABLE",dlgMaximizableWindow

which presumably is where this error occurs. The documentation for tagparameter( states that the equals sign is part of the tag, and the parameter must be quoted if it contains spaces. It doesn’t explicitly state that there must be no spaces between tag and parameter, but on the other hand none of the examples include any, therefore I’d assume so.

3

Peter’s comments are spot on.

The tagparameter( documentation says

each tag parameter takes the form name=value

I guess it doesn’t say so explicitly, but the form shown has no spaces, and in fact no spaces are allowed.

If you do put in an extra space, the tagparameter( function will ignore whatever is after the space. So

name= value

will cause the value to actually be "", not "value".

And that’s exactly what happened to Robert

form= "Duplicate Patient"

is specifying that the form name is empty. Notice that the error message has two spaces between form and does not exist - normally the specified form name would be there but the form name is empty, so you just get the two spaces.

If I was starting from scratch, I would no longer use this technique for options, instead I would specify the options with a dictionary, like this:

rundialog initializedictionary(
    "Form","Duplicate Patient?",
    "Height",120,
    "Width",400)

I think this would be a bit nicer than the current system. However, when rundialog was first written, Panorama didn’t have dictionaries, so obviously I didn’t write it that way. The current system is a bit picky about the syntax, but it works pretty well.

should it say ‘OPENDIALOG’?

Panorama has hundreds of statements that are written in Panorama code. These can generate errors on that internal code, so that the error message refers to the internal code, not the statement that you wrote. In a few cases I’ve added extra error trapping so that the error message doesn’t mention the internal code. But to do that across the board would take a minimum of months of work. If Panorama was a Microsoft product, and millions of people were using it, that investment might make sense. But for statements that are only used by a few dozen advanced Panorama users, there just isn’t the budget for that.

BitBucket but I think that option is no more.

The BitBucket issue tracker was open to the general public for many years, and I liked it that way. Not many programs leave their issue tracker wide open to anyone, but I like collaborating with the community. Unfortunately, a few years ago the issue tracker suddenly got attacked by spammers who were adding multiple garbage issues per day - not even in English, as I recall. Compounding the problem, BitBucket had absolutely no tools available to combat spam. The BitBucket issue tracker only has two modes - wide open where anyone can access (and spam) the system, or private. So I was forced to make it private. I think this forum serves the community better anyway, and I transfer issues into BitBucket as needed, even though you can’t see that anymore.

4

Wow. A whole lot of words that didn’t really educate me much. lol. Sorry about all of that. In another world, prior to posting that, I would have bet $1 that all of what has been said was probably the answer behind the error message. I had already figured out the answer. I did appreciate the background but did not recognize the work that others would put into it. I was just hoping to help the next schlemiel to not have to struggle through it.

I thought perhaps there was some magical replaceMultiple(code,” =”,”=”,”= “,”=”,”,”) type of thing in the Compiler that would take care of this stuff for all of the schlimazels in the world.

5

perhaps there was some magical replaceMultiple

That would indeed need to be magical. If a regular non-magical replace is used, it could very easily replace sequences that you didn’t intend, causing even worse problems than you started with. Especially bad for schlimazels.

For example, suppose your options contained a tag like this:

title=|||Price = Cost|||

Your proposed replace would set the title to Price=Cost - not good!

As an aside, I find replacemultiple( obsolete these days. Sure, it still works, but I find it much clearer to use a regular replace( function, now that the regular replace( function allows you to specify multiple replacement pairs. Check it out.

6

I was not expecting a preemptive alteration of existing, working code, but rather something to the tune of using something like

If Error

that would only be used when the programmer’s code as written failed.

I liberally use spaces in my code to allow my peabrain to more easily read my code and recognize possible errors. I attempt to consistently use chevrons «», & WgVariable coding to easily know the type and scope of my variables and differentiate them from fields or statements.

My lizard brain will forever though get confronted with this less than perfect reference to some alternate, misleading error message. If the computer can be altered to make my use of it easier, I’m all for it. I will always fully appreciate the cost/value decisions, but I too also believe that there are magical things that can be accomplished through my dreams.

7

If you want to catch an error in rundialog and handle it yourself you could use try/catch.

try
    rundialog "..."
catch
    let errorMessage = info("error")
    ... do your thing here ...
endcatch

Hmm, maybe I misunderstood what you are saying.

using something like

If Error

that would only be used when the programmer’s code as written failed.

Maybe you mean that rundialog should notice the “error”, and fix the code. However, this would be even more magical than what you first proposed. There’s no way that Panorama could go from “form does not exist” to “Robert left out a space, let’s remove it for him”.

The code you started with has perfectly valid syntax. It doesn’t do what you want (because you specified an empty form name), but it is valid syntax.

You are building a complex application - that makes you a developer. A big part of the job of being a developer is figuring out why the computer doesn’t always do what you think it should do. It doesn’t matter whether you are working with Panorama, C, Swift, Python, whatever - many times the computer doesn’t do what you expect, and generates a seemingly irrelevant error message or no message at all. The problem domain is infinite, so there’s no way that all possible problems can be addressed in an optimal way. So it’s on you, the developer. We’re told that this job can be done by an LLM, well, maybe so, though I’m not convinced as of yet.

Here’s my dilemma. You come up with a problem, and myself and/or others on this forum come up with a solution for you. But that doesn’t seem to be good enough for you - you seem offended that the problem exists in the first place and want it engineered away asap. Well sometimes that’s possible, sometimes even easy, but the domain of possible problems is infinite, so all possible problems cannot be engineered away. We have to do triage. I challenge you to show me any non-toy development system that doesn’t have endless problems, frustrations and gotcha’s. It’s just part of the territory. Over the past decade Panorama X has had literally thousands of bugs fixed and improvements made, but there’s always more where that came from. It’s way easier to identify problems than to fix them, so there will never be a shortage. But just as your local city doesn’t immediately fix every pothole, no software vendor can fix every bug, or perfectly document every feature. I’m going to settle for doing the best I can. Bringing this back around, the grammar for rundialog options is pretty simple. Reviewing the last decade of forum posts, I don’t see this as a major issue that needs to be dealt with. You just need to remember not to put in extra spaces.

8

And also, just the cost of fixing every pothole and fulfilling all residents’ other wishes would make local taxes tend towards infinity, every extra statement or function call makes a piece of code bigger and run more slowly until it eventually grinds to a halt. It would be relatively trivial to make the very specific addition to allow optional spaces between tag and parameter:

tag=  parameter

but, since in this case the equals sign is part of the tag and therefore can’t be preceded by spaces, I don’t think it makes sense to add further complexity just to allow them after it.

I have sometimes idly wondered why Panorama statements and functions use different ways of supplying options, some easier to use and more flexible than others, but it’s probably mostly down to when they was introduced; as Jim said, this function precedes dictionaries, for instance. It’s one of Panorama’s strengths that it has constantly been extended over the years yet made very little user-code obsolete — I’m sure no-one could have planned anything so flexible yet powerful from the start — but the price of that is a degree of inconsistency. The same goes for documentation because that has evolved too. But at least every user can contribute to making the latter more accurate and/or less ambiguous.

As to errors, I find it harder to debug Panorama code than some other languages I have used, particularly trying to pin down where an error has occurred (especially where there are nested function calls), but then I remember my thousands of lines of 6502 assembler which either worked or, more often, didn’t, with no possibility of any error messages and a good likelihood of overwriting an important OS variable to boot, and I’m glad Panorama provides the debugging tools it does.

9

I have sometimes idly wondered why Panorama statements and functions use different ways of supplying options, some easier to use and more flexible than others, but it’s probably mostly down to when they was introduced

:100:

constantly been extended over the years yet made very little user-code obsolete

:100: