V17. line and v17 R4 in production (4D write -> pro)

Dear,

To approach the conversion from 4D Write to Write Pro I have understood
that v17R4 is the latest version to support 4D Write (32 bit Mac) and at
the same time have the best setup of commands for Write Pro.
In v17. line I am quite limited to be able to code a replica in Write Pro.
Commands for Header, Footer is missing for instance.

Any thoughts or hesitations for running v17R4 in production for a while?
I did use v15R5 for more than a year without problems.

Environment is mainly Mac Client and Mac server app 25 users.

Best Regards
Magnus

What is your goal ?

If it is to use 4D Write Pro, you should use the most recent version of 4D (at least v18)
Under that version 4D Write Pro was only in alpha stage, even the conversion is sometimes not good (bugs, etc…)

But, even in v18 the version is still in development stage (lack of end user interface for some elements like Tables).

And there are https://blog.4d.com/4d-write-pro-and-formulas/new commands> just arriving in the v18R2 versions

BTW the v18 is the only good version for deploying in macOS Catalina (10.15.x)

If you don’t want redevelop your code for each version make the jump directly in v18 (at least).

Dear Manuel,

Goal.
Over years I try to keep up with 4Ds versions and foresee that we are
64 bit and v18 dot or R by the end of this year.

This is an internal application and therefore it is constantly evolving.
Meaning that I need to make additional code changes weekly and
sometimes more often.
For the moment we are implementing changes in the web and also
integrating freight logic. Due to the Corona I also do some refactoring using ORDA.
I always run compiled in production.

We use 4D Write relatively much and build (by code) complete/complex 4D write docs.

In order to have a possibility to make incremental upgrades and at the same time close the gap
between Write Pro and 4D Write in terms of functionality as much as possible side by side before
I leep to v18, I hope that v17 R4 will take me furthest.

Regarding the long time strategy I am a bit confused regarding the new 4D strategy for
LTS and R versions. I think that my application should be an LTS application in production,
however 2 years between releases is a long time, and the “teasers” of v18 R2 functions
will be possible to implement in LTS production sometime during 2021 late or?
I read Blog about Picture manipulation and deletion for instance coming in early v18 R-line.

So if I need such functionality earlier I have to go with the R-Line. A bit off topic, but anyway.

Best Regards
Magnus

Dear Magnus :wink:

I am totally agree with you analyse about the confusion of the new LTS strategy and about the reluctant for using R releases in production.

But, I encourage you at least to use the v18.x (LTS) release if you want really use 4D Write Pro. The versions before were not ready for the conversion and lack of command for really build by programmation 4D Write Pro docs.

And for the web, the new REST server (of the v18) can be a good opportunity too.

We use v17.x version in production too, but your next version will use v18 directly.
Beware that there are still verifications and programmation to do in your actual version so the conversion can work better in v18.

Hope that help you.

I think your best option here is to actually export all you WR7 documents from the database using 4D write and then develop your new 4D write pro interface. Then import all the wr7 document into new object fields and clear the old picture or blob fields you got in your current database. So use your current structure just to Export files to disk then use the latest an “bestes” 4D version to read them back into the system.

Thats what i am planning to do for a customer of mine. I can’t see any other way.

: Johan BRAUN

Then import all the wr7 document into new object fields and clear the
old picture or blob fields you got in your current database.

There are many possible ways and everyone can chose of course what’s best.

I personally would not recommend this approach.
Keep your old documents in blob fields. Don’t touch them, except they are created with 4D Write Versions older than 2004 or they contain pictures in Mac PICT (QuickDraw) Format.
Then, and only then, create a method running with 4D v17 or v16 in 32 bit mode and loop through all documents, convert pict to PNG or JPG and save the documents, to get them in latest 4D Write Format.

When an existing document is to be opened, you check if your object field is empty. Then use the old blob field and just open the document with 4D Write Pro.
If the user modifies and save, save it in the object field and empty the blob field.

This goes super fast (no need to export/import or run migration loop) and allows a step by step approach. And, if you make a mistake/error, you don’t destroy existing documents. And if we made an error in the document migration or we improve that with newer versions (and happened with 4D v18), you benefit from that.

: Thomas MAUL

When an existing document is to be opened, you check if your object
field is empty. Then use the old blob field and just open the
document with 4D Write Pro.
If the user modifies and save, save it in the object field and empty
the blob field.
You should even consider to keep the blob field as is (We don’t know if there are no future conversion bugs corrected for example). For display you only have to test the new object field (#null) to know if it is a new/modified or old document.

yes, good point. Possible as well, of course.

I did it differently, as I expected that if a user modifies a document he/her checked it and accepted it.

But of course this highly depends of the users, there are always people which first modifies many documents and then report weeks later “by the way, the documents are missing parts”…

yes, really important, I know a case where legacy 4D Write documents were accidentally wiped out, because of failed conversion from PICT which resulted in an empty BLOB.

Dear all,

Thanks for all responses.
Conclusion is to hurry to v18 and take advantage of the better language support.
I have gotten a bit with v17 Write Pro, but Stylesheets is the culprit for me.

Storing and older docs.
I consider my 4D write documents relatively compatible with Write Pro.
I have stored them outside database with Blob to Document as well as for
a minor part, in a Blob-field. All open just fine in Write Pro.

My standard saving was like this with 32 bit 4D Write:

Blob_x:=WR Area to Blob(PluginWrite)
transfer the blob to server and store on disk with
BLOB TO DOCUMENT(path_t;Blob_x)

Now with Write Pro I realize that I continued to work as before:

WP EXPORT VARIABLE($p4DWrite->;Blob_x;wk 4wp)
transfer the blob to server and store on disk with
BLOB TO DOCUMENT(path_t;Blob_x)

However I see that there is also a command WP EXPORT DOCUMENT.

Is it recommended to use this Command instead?
Will the stored document on disk be different?
(all documents are stored server side)

Best Regards

Magnus