#563 (ok 3.3.7)Dragging tables to the edge after page size change
Description:
If you choose a larger page size, scratchboard size will be refreshed, but table box dragging will still be restricted to the area covered by the default paper size.
The same problem occurs when changing from Portrait to Landscape (right border can't be reached through dragging) or vice versa (bottom border can't be reached)
Reproduction:
Open scratchboard, move a table box towards to the right and bottom border. Dragging will stop at 2px and 5px before the border of the scratchboard.
Change paper size to a larger format (eg. from A4 to A3). Scratchboard will expand accordingly in size, but the "draggable area" will remain limited to the previous dimensions. Thus, the larger area can be used only by entering bigger coordinate values manually in the text boxes below. An attempt to drag these elements will result in their position automatically "corrected".
Cause:
The area inside which the draggable object can be moved around is defined once (on page initialization) by calling the DOM-Drag method drag.init(),
but not after a change to page size or page orientation (lines 536 and 542 in pdf_pages.php) is made. That is something the function refreshDragOption()
(found in /js/functions.js, line 1382) misses.
Suggestion:
Regroup the init() function in pdf_pages.php: Put all the lines that contain drag.init calls into a separate function that can be used by both the init() function in pdf_pages.php as well as the refreshDragOption function in /js/functions.js.
This new function could probably also check whether there are table boxes out of range of the scratchboard box (in case a smaller page size was selected) and adjust the coordinates so that all boxes are positioned within the visible area of the scratchbox. However, I personally would prefer to adress that issue by adding scrollbars (by adding "overflow:auto" to the scratchboard box) in case there are table boxes out of range. A conscious user should be aware of the fact that paper sheets don't usually come with scrollbars...
I attach a file containing the changes I made to my PMA 3.3.5 installation on an up-to-date Debian "LAMP" machine.
This fix was cursorily tested with Debian Iceweasel, WinXP Firefox 3.6 and WinXP IE8 and works fine for me.
Fix for the PMA PDF scratchboard resizing issue
Moved to Patches
Martin,
it's much easier to understand and implement your changes if they are proposed in a context diff format, see http://en.wikipedia.org/wiki/Diff.
Can you attach here a diff of your changes?
Okay... This was a bit confusing, and the past week was sort of hellish.
Here you are:
/js/functions.php:
1385a1386
> TableDragInit(); /* added call to new function in document */
pdf_pages.php:
352c352
< $draginit .= ' Drag.init(getElement("table_' . $i . '"), null, 0, parseInt(myid.style.width)-2, 0, parseInt(myid.style.height)-5);' . "\n";
---
> $draginit2 .= ' Drag.init(getElement("table_' . $i . '"), null, 0, parseInt(myid.style.width)-2, 0, parseInt(myid.style.height)-5);' . "\n";
387a388
> TableDragInit(); /* added call to new function in document */
389a391,395
> function TableDragInit() { /* new function containing only the drag.init calls */
> myid = getElement('pdflayout');
> <?php echo $draginit2; ?>
> }
>
Note that this was only a "hotfix". It essentially was an attempt to cleanly emulate a feature that is Mootools built-in (the "container" option in the "Drag.Move" class, see below) while still using the older DOM Drag script.
This is how a patch could look like that simply replaces DOM Drag with Mootools (as already included in the package):
pdf_pages.php:
341c341
< <script type="text/javascript" src="./js/dom-drag.js"></script>
---
> <script type="text/javascript" src="./js/mootools.js"></script>
352c352
< $draginit .= ' Drag.init(getElement("table_' . $i . '"), null, 0, parseInt(myid.style.width)-2, 0, parseInt(myid.style.height)-5);' . "\n";
---
> $draginit .= ' new Drag.Move("table_' . $i . '", Table_Drag_Options);'."\n";
386c386,396
< myid = getElement('pdflayout');
---
>
> Table_Drag_Options = {
> container: "pdflayout",
> onDrag: function (el) { x=parseInt(el.style.left);
> y=parseInt(el.style.top);
> i=el.id.substr("table_".length);
> document.edcoord.elements["c_table_"+ i + "[x]"].value = x;
> document.edcoord.elements["c_table_" + i + "[y]"].value = y;
> }
> }
>
See http://mootools.net/docs/core/Plugins/Drag for reference.
As far as I can see PMA in general doesn't make much use of Mootools yet, but I think it would be worth the effort, at least with this particular piece.
Thanks for the patch, I'll apply it ASAP.
About Mootools, we have switched to jQuery for the development version (future 3.4).
Patch merged, thanks. To avoid a notice of undefined variable I changed
$draginit2 .=
to
$draginit2 =
I see. Better idea would be to use this one instead:
328a329
> $draginit2 = '';
That other line is inside a loop over $i, so ".=" is the operator of choice, I think. :)
Implemented better idea, thanks.