Every custom field for each entry shares a common 4k (previously: 1k) storage space.This ones makes no sense!
I have no problems lifting this limit but you can be sure you will experience performance degradation, if you put all this data in a metadata field.Yes, please, then do so. I do understand the possible performance penalties but that's an unlikely situation for most users. I run into additional difficulties while experimenting with PDFe scripts. Currently I'm testing a way to extend Info Field memory by using external files so this is primary just to retain some freedom for experimentation
Allowed field length, for custom fields, is now 1000 characters.Please consider allowing field length to be at least 4096 characters long. We used to have 65K and it had no visible impact on performance. I think this change is not substantial if still compared with 65K.
You will need to update your scripts only if you need to know that a specific field got trimmed because it tried to store a too long string. Allowed field length, for custom fields, is now 1000 characters.
You will need to update your scripts only if you need to know that a specific field got trimmed because it tried to store a too long string. Allowed field length, for custom fields, is now 1000 characters.QuoteAnd why not? But no, the trim will be done internally.Sure we can do that, but it would be nice if you could confirm whether we should update our all CommitChanges procedures in the scripts or not.
Sure, but in the registry you have the previous running session values, not the current ones. These settings are obviously saved to the registry when the specific window close, or the program ends for the main window case.QuoteYou may use this trick to get the full screen resolution.Thanks. I thought that settings like window size and position get saved in the registry by default.
And why not? But no, the trim will be done internally.Sure we can do that, but it would be nice if you could confirm whether we should update our all CommitChanges procedures in the scripts or not.
You may use this trick to get the full screen resolution.Thanks. I thought that settings like window size and position get saved in the registry by default.
And why not? But no, the trim will be done internally.QuoteI'm not getting that DB problem with the long string, but yes the length must be checked and trimmed to an acceptable value.Are you suggesting we should always check that in our scripts before commiting changes?
Can failed file reading (or any other situation) pervent us from using "DB Only" option for saving changes with: CommitChanges(false) ? Correct me if I'm wrong but CommitChanges(false) stands for "DB only" option for changes.No. As long a DB entry exists for the related file, the DB only metadata update will work just fine without checking for/touching the file itself.
By the way, how can we get the PDFe current main window size in pixels?I'm not aware of any ready available way to do it from a Active Scripting script, at least without the help of a third-party COM control, or a script engine with the functionality built-in (i.e. I'm sure it can be done with the ActivePython engine).
var objIE = new ActiveXObject("InternetExplorer.Application");
objIE.Visible = false;
objIE.fullscreen = true;
var width = objIE.width;
var height = objIE.height;
objIE.Quit();
pdfe.echo(width + "x" + height);
I'm not getting that DB problem with the long string, but yes the length must be checked and trimmed to an acceptable value.Are you suggesting we should always check that in our scripts before commiting changes?
Regarding the CommitChanges fail situation. The fail can be related to many things, like file in use, unhandled situation exception (unknown error), etc. A status code is preferable, and may be provided in a future implementation, but knowing that it failed is sufficient to be aware that a file in particular needs to be checked.Can failed file reading (or any other situation) pervent us from using "DB Only" option for saving changes with: CommitChanges(false) ? Correct me if I'm wrong but CommitChanges(false) stands for "DB only" option for changes.