Compile Lockup with 257 dcdialog.ch IF clause changes

[Cliff Wiernik]

It is not really hard to maintain, except if you make a syntax error. Then harder to find since the line number may not be always obvious., but since it is in the new code changes. But this way is easier. You still have the same array values, just with AAdd(aArray,........) around the array.

Cliff.

[rdonnay]

Another thing I would suggest is that instead of using the large array for all your variables, considering using a DCVARGROUP.

[Cliff Wiernik]

Never switched from your original methodology. See my next posting with an issue I found with this.

The help file for DCVARGROUP appears to be truncated.

[Cliff Wiernik]

Roger,

I just tested and confirmed that I would still have to pass the object variable, just like any other defined object in order to access it in called functions or define as a public/private(not desired).

However, I found out something that is not as good.

say you have the following code (which I modified in your vars.prg example)

DCVARGROUP oVars .......
Job := 'Invoice', ;
Name := 'Larry'


test(oVars)

return

function test(o)
LOCAL o1
dc_debugqout(o:job)
dc_debugqout(o:name1)
dc_debugqout(o1:name)
return nil

When the dc_debugqout(o1:name)

This just terminates the program on the erroneous statement o:name1 or if this commented out, o1:name. Either statement is wrong and will not generate warning message. No error message appears, not xpperror.log file is created and no xppfatal.log file is created.

Thus, you don't know what happened. It is like a sponteneous termination. This is not very good. Am I missing something. It is a powerful function, but error recovery appears to be a problem without it generating error logs or and error object. It is easy to make a programming mistake, but without error reporting, it would be hard to manage.

Cliff

[rdonnay]

Cliff -

What you found was a bug in DC_InspectObject().
It posted a temporary error handler but failed to restore the original error handler.
Comment out DC_InspectObject() in the code and you will see what I mean.

It will be fixed in build 258.

The advantages of using a vargroup instead of an array are the following:

1. Variable definitions are not case sensitive.

2. You can inspect the vargroup object with DC_InspectObject() and you can see the var names and values.
You can't do that with an array.

3. You can define the name of the var and initialize it to a value at the same time.

4. You can use the vargroup object anywhere in the program without needing to have the definitions at compile time.
The array concept only works in a single .PRG file.

5. You can receive the vargroup in a called function as Self and then don't need to remember the object name.
Example:

Code: Select all

function test( Self )

dc_debugqout(::job)
dc_debugqout(::name1)
dc_debugqout(::name)

return nil

[Cliff Wiernik]

For #5, is it correct in saying that you still need to pass the VarGroup object to the functions you are calling. You can reference that object as "Self" in the called function but you still need to pass it, unless you defined the object as a PUBLIC/PRIVATE.


As for the array definitions. We have already encountered that where we need to make certain we have common defines in other program files when using the array approach and must keep common variables in the same array position.

Cliff.

[rdonnay]

As for the array definitions. We have already encountered that where we need to make certain we have common defines in other program files when using the array approach and must keep common variables in the same array position.

You have made my point.

[Cliff Wiernik]

Tested this without the dc_inspectobject() and works properly now.

Is there any advantage to using self and ::xxxx versus using a variable name like oVars and oVars:xxxx.

Cliff.

[rdonnay]

Is there any advantage to using self and ::xxxx versus using a variable name like oVars and oVars:xxxx.

Less typing and chance of making a mistake, i.e. o:xxx and o1:xxx per your example.

There is only 1 disadvantage: Unfamiliarity with the code may cause another programmer to wonder how Self could be used in a function rather than a method if you have standardization rules. Alaska made a point at the Hanover devcon that they will be publishing their own programming standards soon to share with the Xbase++ community. Unfortunately, most programming standards don't prevent a programmer from writing bad code, and actually can hinder creativity and productivity.

"Big Brother" language standards would likely have disallowed a concept such as eXpress++ because productivity isn't as important as elegance. Personally, I think eXpress++ is very elegant, that's why I wrote it. I have done things over the years that were quite the folly, but the eXpress++ method has stood the test of time. I don't expect the FoxPro community to even give it a second look because they get their marching orders from Microsoft.