Update the Word UDF that comes with AutoIt (former WordEX thread)

[water]

Correct,

Trancexx told me - and I had to admit - that a function that only consists of a single line doesn't make much sense.

So instead of calling _Word_DocPropertySet you directly set the property using

$oDOC.BuiltinDocumentProperties("Property").value = value

Edit: Code corrected

Edited December 18, 2012 by water

[BrewManNH]

The line to set the property, in the UDF at least, is "$o_object.BuiltInDocumentProperties($v_property).value = $v_newvalue". Just an FYI.

[water]

Oopps ,

BrewManNH is correct. I have been playing too much with Outlook lately.

[Jury]

Thanks BrewManNH and water.

Joe

[water]

Version 1.3 of the UDF has been released!

Have fun testing!

[water]

The latest version of this rewrite of the Word UDF has made it into the AutoIt repository.

So starting with the next beta release all scripts have to be modified for this new UDF.

[trancexx]

Don't forget to list possible script breaking changes into the changelog.

Edited January 18, 2013 by trancexx

[water]

Added this line to autoit_changelog.txt and autoit_changelog_complete.txt:

- Changed: Word UDF was completely re-written. Function names changed from _Word* to _Word_*. THIS IS A SCRIPT BREAKING CHANGE.

But I couldn't find the source for script_breaking_changes.html in the repository. Do I have to change the html file?

[trancexx]

Remove the UDF version number. There should not be such thing. And you have to document every (other) script breaking change. Users have to be able to find information about why their scripts no longer work.

[water]

1) Done

2) Will do in the script_breaking_changes.html file.

Valik once talked about that all documentation from the function header lines has to be removed and the documentation only has to be made in the text files where the help files are generated from.

What's the latest on this?

[trancexx]

Nothing is new on that.

Your _Word_DocFind should be more like _Word_DocFindReplace when it comes to working with Find object. If your code uses more calls to this (any) object then save it to a variable to avoid unnecessary name lookup.

[water]

And you have to document every (other) script breaking change. Users have to be able to find information about why their scripts no longer work.

The whole design of the UDF has changed so I think it would be best to describe it in the wiki as I have done for the OutlookEX and AD UDFs.

The script_breaking_changes.html will only have a short notice about the changes and link to the wiki.

Is that OK for you?

[trancexx]

Wiki biki... I'm not sure what you want me to say. Changelog must include all (script breaking) changes.

[water]

I will document all the changes. But caused by the rewrite there are so many changes it will bloat the changelog.

The massive UDF changes which came in 3.2.12.0 where documented in a separate forum thread.

So I suggest to document the Word UDF changes either in the wiki or in a forum thread (I prefer the wiki).

[trancexx]

Then rename the new UDF to MSWord.au3 and restore the old one. Remove the help file references to old file completely and remember to remove it from the package when users switch to the new (few betas away from today). Add references to the new file in the help file. Update changelog accordingly.

[water]

From the slow feedback I got from my I get the impression, that not too many people do use the Word UDF and even fewer will be affected by the script breaking changes.

I therefore suggest to completely replace the old Word UDF with the new one (as I already did) plus document all script breaking changes in the changelog (please see the attached PDF for a complete list).

When users start to test with the next alpha or beta version of AutoIt there is sufficient time to change their scripts.

If they don't want to modify their scripts they still can stay with the current AutoIt production version or use the old Word UDF with the next AutoIt production version.

What Changed.pdf

[trancexx]

Don't make assumptions based on feedback from the forum. Majority of people using the language don't use the forum as registered users, if you look at the number of downloads of AutoIt.

The number of changes are too big to do it the way you suggest. Still you don't have to do it the way I suggested if you don't like it. Work out new scheme then.

[water]

I see. In this case I suggest:

• Completely replace the Word UDF with the new version (including help files, examples etc.).
• Add a detailed list of script breaking changes to the script_breaking_changes.html. Add a comment that the old UDF is still available as MSWord.au3
• Add the "old" Word.au3 as MSWord.au3 for those who still need the old version

So the user gets best of both worlds.

[Spiff59]

Should an issue we chewed on in the Excel UDF also be addressed here...

If you call _Word_DocOpen with $bReadOnly = False, intending to update the document, and the document is already in use by another network user, shouldn't there be an error generated? Some mechanism to let the user know they did not receive a lock on the file and will not be able to save any changes?

PS - The old _WordAttach() function did have the word "existing" in it's main description. Just to eliminate possible confusion, i think it might be a good idea to insert the word "open" (or something similar) into your _Word_Attach() description, like: "Attaches to the first instance of an open Word document". I do see that the descriptions for 2 of the 3 possible values for the $sMode parm do specify "open document".

[water]

Hi Spiff59,

ReadOnly: Good idea. Will test and let you know.

Attach: Will have a look and edit if needed.