MCA,

Responding to your points to me.

quote:

About backwards compatibility:
when people where using an earlier version of our packages during deployment we must
cleanup the mess from those earlier versions.
when people where using only latest versions of our packages it isn't necessary to
do that. In our script above we doesn't use "c:\kix???.ok" at all. We have to deal
only with the "%windir%\kix???.ok" control file.
So, you are trying to make a "one size fits all" solution? There are times where the person cannot upgrade KiXtart..

In testing with a "locked down" user, we could not write to %windir%..

quote:

We don't think, that you of anybody else
love it to modify our reduced version with variable names like $x1, $x2, ...., $x35.
In coding, I try to keep some meaning to variable names, just shorten them.

quote:

About parenthises
some language makes it possible that you are using short versions of available keywords.
of course typing the short ones doesn't cost much time, but reading those code many
years later make it very hard to understand what it means and to maintain.
Hard to maintain? For who? If you have mal-formed syntax, then yes I could see your point. It makes it really difficult for you to have one standard and everybody else have quite another. Does it mean that the code works better? I would argue against that with an emphatic NO!!

Let's take for example the following code:
code:
IF (0=INGROUP("GROUP"))
 ;DO STUFF
ENDIF
It is much better to do:

code:
IF 0=INGROUP("GROUP")
 ;DO STUFF
ENDIF
If we think about this from a processing perspective, if these can be reduced, login time for example, is reduced. We all have to deal with people complain about login times anyway. If we can shave these off, even a few seconds, the better!

As another argument here, with the newer versions of KiXtart, Ruud has been kind enough to implement internal error control and displaying the error and the line number the error is coming from.

code:
About going back ... with the 3.6 version
everything is incorporate in same script.
Why? Portability maybe a fair argument.. However, if you we look at the $os variable you use, why not use the Macro @PRODUCTTYPE instead with the new versions. I hate to pull other people into this discussion, but if Jochen/Jooel stayed with their original code with PostPrep/BBChecker, would it still work? Sure, these products work in their beginning versions, but they improved on it. Hence, they made it better!! Can't you/we do the same for KiXnnnUpdate.EXE program?

This process this should be a experience of how we do our practices better!!

Regards,

Kent

[ 30. April 2003, 15:07: Message edited by: kdyer ]
_________________________
Utilize these resources:
UDFs (Full List)
KiXtart FAQ & How to's