Ditto what Tim said. His description of the process is comprehensive and realistic. I had about 120 methods and forms to re-write. Took 3 months, but hasn’t been deployed due to a constraint on testing resources. Some level of support for Automated Testing in 4D would be nice in a case like this.
Tom Benedict > On Feb 5, 2020, at 08:07, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> wrote: > > 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 > timnev...@mac.com ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
