On Feb 5, 2020, at 8:42 AM, Peter Jakobsson wrote: > I’m going to be making the leap from v15 to v18. I think the biggest > transition will be moving to 4D Write Pro as I have quite a lot of legacy 4D > Write code to deal with. > > In the meantime, does anybody have experience of migrating big 4D Write > codebases ? What are the major gotchas ?
Warning: You may not going like what I have to say below. You are late to the game and a direct v15 to v18 upgrade may be very challenging. This is a long post for everyone that is going to move to v18+ some day and is currently using the 4D Write Plugin. I’ve done a big code rewrite from 4D Write Plugin to 4D Write Pro in v17. There are many gotchas. You will need to throw away all of your 4D Write Plugin code and start over, from scratch to do duplicate the functionality using 4D Write Pro code. There is no one-to-one, command-to-command mapping between the two. Some things in 4D Write Plugin code that take 10 lines of code now take 2 lines in 4D Write Pro. Some things you can’t do at all, and don’t want to or need to do. In some cases you have to use styled text commands to do operations on 4D Write Pro areas whereas with 4D Write Plugin there was a plugin command. 4D Write Pro is based on an object field and an object variable. Some things are done by manipulating properties of that object. You will spend a lot of time tracking down what those property names are and how to set and change them to accomplish what you did with 4D Write Plugin commands. The documentation for 4D Write Pro is divided between 4D Write Pro commands — which there are very few compared to 4D Write Plugin’s many commands — and object property manipulation and styled text commands. Some native 4D object commands also work and are needed to make changes to 4D Write Pro objects and areas. You also manipulate 4D Write Pro object areas using “standard actions” that can be assigned to a form button or UI element. You also sometimes need to invoke one of these actions to accomplish what you need that in 4D Write Plugin you did with a 4D Write command. You use the INVOKE ACTION command for that. It’s a new way of doing things that takes some getting used to. Read the docs. Then read them again so you get a sense in your mind of what you must do with standard actions and the INVOKE ACTION command. https://doc.4d.com/4Dv17/4D/17/Using-4D-Write-Pro-standard-actions.200-3726284.en.html 4D Write Pro implements probably 95% of the 4D Write Plugin features and capabilities. Might be 99%, but it is not 100%. Maybe you will not miss the 5%, maybe you will. You’ll find out when you get into the complete rewrite of your code. No, I don’t have a complete list of the missing 5%. For my project I lost 2-3 small features that I was able to live with. Convenience things for the user interface and to help users that were not a big deal. It took me two full 8 hour days of 4D Write Pro immersion to get my head around how it works when compared to how 4D Write Plugin works. Maybe you only have 50 lines of 4D Write Plugin code that you need to convert. Then you have maybe a day or two of work and you are done. If you have 200+ lines of 4D Write Plugin code spread over 50+ project methods and form object methods, it’s gonna be a multi-day project. You have to factor in retesting EVERYTHING. That adds the most time to the rewrite. Testing EVERYTHING again. > Will legacy 4D Write work in v18 in the meantime or do we need to migrate to > 4D Write Pro to even run it ? (When I try it it invokes license privilege > errors everywhere). 4D Write Plugin is 32bit only. v18 is 64bit only. So zero 4D Write Plugin code will run. You can keep the 4D Write Plugin around after the v18 conversion so you can still read the 4D Write Plugin code, but none of it will execute. It’s 32bit and 4D v18 is 100% 64bit. > Many thanks for any tips My advice is to not move from v15 to v18. Instead, move from v15 to v17 first. 4D Write Plugin still works just fine in v17 32bit. And it can coexist with 4D Write Pro. Same license works for both. So you can fork your code and keep all the current 4D Write Plugin code and form areas working just as they are. Users can continue to use them with the 32bit client. 4D Write Pro also works just fine with 4D v17 32bit. So you can run 4D v17 32bit and do all the testing and coding for 4D Write Pro. You can also run the 4D Write Plugin code in 4D v17 32bit. So you can test the current 4D Write Plugin code against the new 4D Write Pro code. That’s how I did all my conversion work. You will also need to convert all the 4D Write BLOB fields to an object field for 4D Write Pro. If you are storing 4D Write areas in a table in a BLOB field, create a new object field to store the 4D Write Pro area. To convert 4D Write BLOB field to 4D Write Pro object field use code like this: [LetterTemplates]LetterPro:=WP New([LetterTemplates]Letter_) Put that in the trigger of the table and any changes you make to the 4D Write Plugin field will immediately get converted and saved to the 4D Write Pro field. That lets 4D Write Plugin and 4D Write Pro coexist during the conversion process. (There is no way to convert 4D Write Pro object back to 4D Write Plugin BLOB.) I used an IP variable that I could turn on and off to set whether to use 4D Write Plugin or 4D Write Pro. Methods can check this IP variable and then branch to use 4D Write Plugin code or new 4D Write Pro code. Use this with 4D 32bit. Check if 4D is 64bit, if so you set the IP variable to only allow 4D Write Pro code to run. When we move to v18 later this year, I will remove the 4D Write Plugin and then attempt to compile. All the 4D Write Plugin code will immediately appear everywhere as errors. I can then move method-by-method, form object-by-form object to strip out the code. I’ve already got in place 4D Write Pro code that accomplishes the same work — controlled by the IP variable — so as I remove the 4D Write Plugin code and delete the 4D Write Plugin methods I can remove the branching control code as it will no longer be needed. That’s my plan. One last thing to consider. 4D Write Plugin was all done in "72dpi macOS" resolution. 4D Write Pro areas have the option of running in "96dpi Windows or Web” resolution. There is also “automatic”. Running in 72dpi makes it look the same on macOS and Windows. But if you want higher quality, switch to 96dpi, but then everything in the area is smaller. So you may want to deal with that. I took the easy route and set it to 72dpi so that it all works the same as before and on macOS and Windows. Final tip, read ALL the 4D Write Pro docs. Read every word of every section. You will be glad you did. This will give you a sense of what you can do with 4D Write Pro and how to do it. https://doc.4d.com/4Dv17/4D/17/4D-Write-Pro-Reference.100-3726274.en.html Good luck on your conversion. Tim ***************************************** Tim Nevels Innovative Solutions 785-749-3444 [email protected] ***************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
