Moving ZPropertyArray to a separate unit?

[aehimself]

Michael, this question is for you. I am trying to enumerate all the useable properties with a program from ZPropertiesEditor. The problem is, to be able to compile that my project needs a TON of other imports, reaching a unit called "DockForm" which doesn't seem to exist on my PC (wtf...?)
Would you have any objections, if I'd move the property array (and it's connected functions, like loading / getting / etc) to a separate unit, so it can be used by an external program?

I was thinking of ZPropertyArrayDef.pas.

P.s.: what is the reason of the heavy use of pointers instead of array of records here?

[EgonHugeist]

Hi,

I am trying to enumerate all the useable properties with a program from ZPropertiesEditor.

Sound dangerous to me. The properties (yet) are not complete or some may be omitted. Example: Yesterday morning i discovered the method: IZStatement.SetQueryTimeout. Yet u use the query-timeouts as parameter DSProps_StatementTimeOut/"StatementTimeOut" for SQL-Server. IIRC there is only ODBC/OleDB and FB4+ able to handle that option. That's why the property is surrounded by:

Code: Select all

{$IF DEFINED(ENABLE_ODBC) OR DEFINED(ENABLE_OLEDB) OR DEFINED(ENABLE_FIREBIRD) or DEFINED(ENABLE_INTERBASE)}...{$IFEND}

Some of the properties are not fully ported yet (some of ASA iirc).

Would you have any objections, if I'd move the property array (and it's connected functions, like loading / getting / etc) to a separate unit, so it can be used by an external program?

as long this unit is part of the designtime-packages, i don't have objections. Note adding a new unit isn't a trivial thing. I don't use the IDE's for the job anymore. I use a simple texteditor todo that, the IDE's always tends to update more lines in the dpr's/dproj's/lpr's than required. So a new unit needs to be available in !all! packages.

I made the unit as an proposal for you and Fr0sT and was waiting for a feedback. Define all the constants wasn't a funny job so i understand how much time Fr0sT did spend to move all the "magic" Strings into ZDbcProperties. The more (as you propably noticed) it's now always a duplicate job to maintain the properties. That's error prown and costs too much time. While i (lonly rider again) try to move the pas2doc documentations to docinsight/model-documentation generation (see https://sourceforge.net/p/zeoslib/tickets/395/) i noticed that complex infos for a constant are possible:

Code: Select all

  /// <type>String</type>
  /// <alias>ConnProps_Password</alias>
  /// <usage>Connection</usage>
  /// <syntax>Properties.Values[ConnProps_PWD]=password</syntax>
  /// <summary>
  ///  Provides a password for a connection.
  /// </summary>
  /// <remarks>
  ///  The Password (PWD) connection parameter is not encrypted. An application
  ///  can include the password in the connection string. If both the Password
  ///  (PWD) connection parameter and the EncryptedPassword (ENP) (if supported)
  ///  connection parameter are specified, the Password (PWD) connection
  ///  parameter takes precedence.
  /// </remarks>
  ConnProps_PWD = 'PWD';

as i wrote already i would vote for moving all the doc's of ZPropertiesEditor into the XML syntax of ZDbcProperties and a smart unit parser would be nice: dynamic load the properites from the ZDbcProperites.pas @designtime/unit initializtion by converting the XML docs into that arrays. That's why i can't say if the declared properties will survive or not.

P.s.: what is the reason of the heavy use of pointers instead of array of records here?

Which arrays/pointers? if you mean

Code: Select all

TZPropertyProviders.Items or TProtocolArray or ..

than it's because the Old compilers can't handle dynamic constants. That feature has been added in XE8 i guess and i dont know if FPC would supported that inbetween. If you're talking about the PZPropertyRefDynArray than it was propably because of the sorts in the properties.

Summary: I wouldn't do that YET. Is there an volunter to test such an unti-XML parsing job? Yet i can live with what we have, ae.

[aehimself]

Sound dangerous to me. The properties (yet) are not complete or some may be omitted.

That does not really concern me. Even if I manually copy all possible properties the same rules apply. Correct me if I'm wrong, but I can put whatever I want in ZConnection.Properties; only the valid ones are going to be used. The rest will make no difference, not raise errors.
I just want to avoid manually copying all properties, that's all.

as i wrote already i would vote for moving all the doc's of ZPropertiesEditor into the XML syntax of ZDbcProperties and a smart unit parser would be nice: dynamic load the properites from the ZDbcProperites.pas @designtime/unit initializtion by converting the XML docs into that arrays.

Ah, well. Byt the enormous amount of work went in this property editor I thought this will be it's final state. I agree with the XML documentation, but... how exactly you imagined reading out XML comments runtime, especially if the source file is not available?
Best I have in mind is to run an interpreter, which collects this information and rebuilds a unit from this information. Then, run this interpreter with each build in Jenkins.

Which arrays/pointers? if you mean

Code: Select all

TZPropertyProviders.Items or TProtocolArray or ..

than it's because the Old compilers can't handle dynamic constants. That feature has been added in XE8 i guess and i dont know if FPC would supported that inbetween. If you're talking about the PZPropertyRefDynArray than it was propably because of the sorts in the properties.

Didn't know that, makes sense this way.

Summary: I wouldn't do that YET. Is there an volunter to test such an unti-XML parsing job? Yet i can live with what we have, ae.

Maybe I'll just write a parser for myself, which extracts this and creates a new unit for my application. I am willing to test the XML parsing (if you mean to run PasDoc on the whole Zeos), but I don't yet understand the logic between these two.

[aehimself]

Okay, big success. Turns out if you tick "Link with runtime libraries" the unit will compile perfectly.
I managed to access ZPropertiesArray and it's contents.

I will write a separate application to "convert" these properties to something my program understands.

Just one confirmation... if .Protocols is empty, it means that the property is valid for all protocols, right?

Cheers!

[aehimself]

Beautyful!

Untitled.png

[EgonHugeist]

Nice!

I agree with the XML documentation, but... how exactly you imagined reading out XML comments runtime, especially if the source file is not available?

yeh we had that already. You are right. So the easiest way should be a smart tool to generate the Properties for the designtime editors from the ZDbcProperties.pas file. The tool might also be part of the designtime packages using an OpenDialog f.e..

Thought, help in any kind is welcome..

[aehimself]

I used this small parser I wrote. Unfortunately - since runtime packages must be linked - only 32 bit is possible, as the IDE has no 64-bit version.

It will enumerate all properties and creates a unit to return properties for a specific protocol. While it is functional, I still see it as a workaround only, as I manually have to re-generate this unit from time to time.
Fyi, the generator is buggy and doesn't cut strings into 255 character pieces correctly. As it makes only a low number of mistakes I decided to fix those by hand instead of debugging :) The parser was created in under 10 minutes without much care so don't expect miracles :)

[EgonHugeist]

Hi ae,
thanks for sharing your code. I quickly did check it and IIRC you're using the ZPropertiesEditor.pas. I was looking for an Parser of ZDbcProperties.pas sry. So it's not helpful 4me but propably for others who want todo slt you're doing.