Post reply

Name:
Email:
Subject:
Message icon:

Verification:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: RTT
« on: December 18, 2016, 12:23:59 AM »

Every custom field for each entry shares a common 4k (previously: 1k) storage space.
This ones makes no sense!
What I said previously is that all the custom fields, for each file entry, must fit in a 65536 bytes common storage DB space. If the sum of the length of the custom fields for each entry exceeds this value, the last fields that don't fit get trimmed/discarded.
Posted by: Padanges
« on: December 16, 2016, 11:13:57 AM »

In addition to this, please help to get the numbers straight:
Custom field count limit is 100.
Allowed custom field length is 4096 (previously: 1000) characters.
Every custom field for each entry shares a common 4k (previously: 1k) storage space.

Is that correct? I need to assign values for limit constants.
Posted by: Padanges
« on: December 16, 2016, 09:09:04 AM »

Quote
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 :)
4K should be just fine. 1K is too restrictive, IMHO.
Posted by: RTT
« on: December 06, 2016, 11:11:04 PM »

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.
Posted by: Padanges
« on: December 01, 2016, 08:14:47 AM »

Quote
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.
Posted by: RTT
« on: November 22, 2016, 11:55:40 PM »

No idea. Depending on the utilization of that list, maybe you could attach it to the PDF?
Posted by: Padanges
« on: November 22, 2016, 10:35:23 AM »

After your increased limitation implementation  I will need a new way to store cross-reference ID lists. Maybe you could advise how to implement a "longer string" saving to the db using PDFe?
Posted by: RTT
« on: October 22, 2016, 03:59:32 PM »

The custom fields are implemented in a way that all (100 possible) share a common 65k maximum storage space, so if you put 65k in just one field, there will be no space left for any other. Having a common ground limit is desirable. Even because, storing such amount of data in the fields would affect badly the program's responsiveness.
The standard fields are limited to just 255 bytes and it's sufficient for common scenarios.
Posted by: Padanges
« on: October 21, 2016, 01:04:17 PM »

Quote
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.

This is a sad thing. I've hit the limitation while simulating for possible cross reference, legacy tags etc string overflow. Perhaps you could leave a possibility to have a 65K char limitation (or even more?) as an optional check in Custom Fields Settings while creating (Ading) new Custom Field? I think there's a need to have a possibility to expand string length for specific info fields.
Posted by: RTT
« on: October 15, 2016, 04:48:21 PM »

Quote
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 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.

Quote
Quote
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.
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.
Posted by: Padanges
« on: October 14, 2016, 06:56:21 AM »

Quote
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.
Quote
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.
Posted by: RTT
« on: September 30, 2016, 04:24:24 PM »

Quote
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?
And why not? But no, the trim will be done internally.

Quote
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).

You may use this trick to get the full screen resolution.
Code: [Select]
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);
Posted by: Padanges
« on: September 30, 2016, 07:58:23 AM »

Tooltips could also limit string length relative to the main Window size. I have had situations (messing around with LONG_PATH file names and Custom Field Info char limit) where the string would not fit into a tooltip, and the tooltip used to take whole screen width, even without showing that long string at all.
By the way, how can we get the PDFe current main window size in pixels?
Posted by: Padanges
« on: September 29, 2016, 09:13:35 AM »

Quote
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?

Quote
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.
Posted by: RTT
« on: September 28, 2016, 03:56:43 PM »

I'm not getting that DB problem with the long string, but yes the length must be checked and trimmed to an acceptable value.

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.