[Solved] Resize control crashes Base

[MSPhobe]

Sigh. After several days uneventful progress building tables, forms, and now reports for a new database, today a very unwelcome development...

A report created this morning was working fine. I went to re-size one of the controls (a label, to be specific), and at first nothing happened, and then my mouse pointer changed to the little animated "progress" icon... and eventually Windows reported "not responding".

Base would shut down (if forced by Windows), and on reopening the .odb file, all seemed okay (after a recovery cycle, and, of course, recent changes to the database weren't present.) But again (and again and again), as soon as, when editing a report, I try to re-size a control... any control, any report, it seems... I get the same behavior. (I haven't wanted to invest the time in trying to create a NEW report at this stage...)

Windows 7, Base 3.4.1, Java 1.7.0_13... Report created with Report Builder... now built-in to Base? (I don't recall installing it as an add on on this machine.)

Thanks for any ideas, help you can offer!

[Hagar Delest]

Resetting the profile may help: reset your OpenOffice user profile.

[MSPhobe]

Hmmm...

Well... progress of a sort.

I reset my profile... and along the way learned that I had indeed installed the Oracle Report Builder... had to re-install that, and my MySQL connector.

Also discovered that it is not EVERY report in my .odb that is buggy... One DID allow me to resize a text box. But others still brough on "not responding" as soon as I tried to edit their size by dragging the drag points.

So... thank you.. but... other ideas, please?

---
I can MOVE a control... (drag it when the mouse pointer is the four headed arrow)... but not resize (drag one of the sides). And no, it isn't just that I am trying to drag it on top of something else. That wouldn't throw the program into not responding, would it? (Rhetorical!)

Both trying to resize a label and trying to resize a data field will trigger the crash.

The good news is that I have crashed, forced quit, done "recover" a number of times now, and the rot doesn't seem to be spreading, anyway. But those reports which I can no longer edit were not simple to set up... although I did nothing fancy, it's just that there are numerous fields involved, and not being confident that they are working properly is un-nerving.

----
The problem doesn't seem to arise in form design.

In the report design (and, to repeat, I am using the Report Builder), when I tried to place a new text box or label field in the page footer, even when it had only just "arrived" on the form, it was behaving strangely when I tried to drag it to a new position. And, as soon as I tried to re-size it: Base went non-responsive.

"Strange" things I did with the report's design before it died... somewhat approximate, but as best as I can remember:

- Moved some of the wizrd created column labels from Detail band to PageHeader band
- Fiddled with Header band... made height zero. Tried Visible yes and no, "Turned on" (and off) with tick-box at extreme left of screen. Hmm... may be something to do with these bits of fiddling... as I "play" with it now, I can't get it to display a band of any height other than 0 in the GUI, even though I can set the band's height property to various non-zero values.

---
Ha! More strange behaviour arising if I fiddle with the height property of the Header band... the blue one, group header, I think. (I have no grouping in the report in question, by the way.) Just setting that to zero is enough to cause problems. Also, when I'd been fooling with it, and then moved the lower edge down, with the GUI, I only had a little bit of "workspace" for the header. (Still GROUP(?) header, NOT page header.) But when I reloaded that report for editing, then the usual "grid of dots" surface was present for all of the (group) header area of the report.

[Hagar Delest]

As a dirty workaround, you can make a copy of your file, rename it as .zip, open it with an archive manager and look at the content to spot the report file, then edit the properties of the relevant field. Sometimes, just setting a different value by-pass the problem and then you can resize it as you want.
But there is some digging to find out how the report is coded in the ODF file and then find the correct field properties...

[MSPhobe]

Rename as .zip/ open/ edit...

Ha! THAT was an interesting exercise!!! Brings my respect for the OO programmers... already high... to "the next level". I commend trying this sometime to everyone! (ALWAYS ONLY work with a copy when getting adventurous like this, as was first pointed out by the following post. This reminder a PS.)

Anyway... found a place which seemed as if it might make the height of the group band not zero. Change the value. Saved the file. Re-zipped everything.

On first attempt, had only re-zipped bits of the original (duh). Got the re-zipping right later, but turned out I had NOT found the right value to tweak.

Thank you Hagar for that excursion into the depths!

[RoryOF]

At the level of examining/editing the contents of the OpenOffice files, which are a compressed archives, one should always work on a _copy_ of the file, made at system level.

[MSPhobe]

Edit:

Ta da!!!.... I MAY have found both cause and cure...

My report had one of the BLUE "Header" bands... the one that appears below the PAGE Header band. And, somewhere along the way, I'd set the height to zero. Bad Idea... and if more dedicated, more knowlegable people can recreate the problem, and submit a formal bug report, I'd be very grateful.

After I'd done that, if I went into the report, tried to edit it further, as soon as I tried to resize a label field... either width or height... Base would stop responding.

Several hours of struggle, but I found, I hope, a fix:

I opened the database yet again. Opened one of the offending reports for editing. Clicked on the BLUE Header Band ikndicator at the left of the screen. Over on the right, in the band's properties, I used the up arrow to just slightly increase the height of the band. Clicked in the box for a different property to "post" the changed band height. DID NOTHING ELSE before saving new version of form, closing down the database, closing down OO.

Then relaunched. And the report can be edited again!! Whew, hurrah.

Had to repeat process with the other report I'd rendered un-editable.