again an issue with PDF inserted in a container. First, here is how the container is set up:
The OS is Windows 10 20H2 latest patches installed. Last time I used my application, I first updated it to 19.3.2.206. I added a few records and as usual I the PDF document was set in the Container by dragging it from the File Explorer to the container. The containers in the records that were set after the update worked as usual, I must say seemed to worked fine. Things is when I close the app and reopen it, these containers are empty. I dragged the files again - no I didn't forget to commit the record by clicking in the background, closed the app and reopen, gain the PDF was gone .
But just as I was writing this post, I tried something else: instead of dragging the file to the container, I right-clicked the container, picked Insert PDF ..., and this time the file remembered the PDF that was set.
So, did one of you experienced this issue ? Is it yet a regression bug ?
It's a bug caused by throwing in new features at a rapid pace without getting your former codebase in order. It seems to me that other companies can manage that by having the long-term support versions and the cutting-edge-user-beware versions. Stuff like that makes me doubt the understanding of Claris' "software engineers,' that their software is often in mission critical applications and should be engineered with that in mind. More often than not it seems like they think their customers are more attracted to the latest "shiny object" than having something that will work correctly day-in and day-out for their business. I don't know who they've been talking to, but I run into more of the latter.
A bug maybe, but it is an artifact of moving to EDGE as the Windows PDF viewer. You can easily code a workaround. I just did this for a client application with almost 500 layouts with PDF viewers on them (30M records, 500 users, almost 3,500 layouts).
.