modify report layout runtime version (1 Viewer)

Hello,
Is it possible to move (slightly) some textboxes on a report, to match a preprinted document, if my database run in runtime version? I need to do that from time to time, when the preprinted document is not "perfect".
I know that runtime version doesn't have any design capability, so users can't alter form/report design but, I also learned that some of the functionality can be restored with more work from developer. Right now I am investigating the customized ribbon "path" with contextualTabs, xml etc . It is a lot of work and I need to know if is possible at list. Of course, any other solution / suggestion will be well received. Many thanks.

the only way that can be done is for the developer to write an editing facility in include within the app. However I'm not sure you would be able to 'edit' a report layout anyway. You may have to have a form which mimics the report layout and 'edit' that instead.

It may also require at least one additional table to record details such as report name, control name and control size and position properties if these small changes need to be retained. This table would have to be interrogated by the report when opened to reposition controls from their 'default' position.

The only other thing to do is to use a report generator to generate your own reports - google/bing 'report generators' or 'free report generators' to find one that might suit.

Thank you CJ_London for your advices. I will try to investigate in depth both of your suggestions. Until then, I need to know for sure if restoring report design/layout functionality with custom ribbon is it possible (or not) in runtime version of ms access.

I need to know for sure if restoring report design/layout functionality with custom ribbon is it possible (or not) in runtime version of ms access.

Click to expand...

Absolutely not possible

You can probably still alter the print margins if that would be sufficient to correct the problem?

To CJ_London: I've searched trough idMso's of access controls provided by Microsoft and, indeed, it seems that what i need is not included. But, because there are 'only' 1478 of them, I was hoping that I just missed something. So, thank you for telling me that is 'Absolutely not possible'.
PS Can you post a link to a 'editing facility' that you described in your first answer?
To Minty: Unfortunately it will not be sufficient. I discovered the idMso's to do that but is not enough. Anyway, thank you.
Now, interesting part is that when I am in runtime mode and I set my report to open in design or layout view, it will open blank but, if I press ctrl+A, I can see the contour of all my text boxes and I can move any of them. Not at all an elegant solution but, if I will not find another way... Did you know about that ?

PS Can you post a link to a 'editing facility' that you described in your first answer?

Click to expand...

Sorry, no. A developer would need to create one. I'm not aware of any documented in this or other forums

If you mean the report generator, just google 'report generator', there are plenty out there.

You could always invest in a full version of access, it is not a lot of money. However if you have been supplied with a .accde, you will still not be able to edit the report.

To clarify: Full Access and Runtime Access are different applications (just as excel is an application), the latter will only run pre existing files and has limited functionality around menus and ribbons. The former does this and also enables you to modify existing .accdb files and create new files.

There are basically 3 types of files

.accdb - these can be edited with full Access, subject to any password protection

.accde - these cannot be edited even with a full version of access. The code, forms and reports are 'compiled' and created from a .accdb

.accdr - are a runtime extension, used be developers using a full version of access to mimic running in a runtime environment.

First of all, thank you, CJ_London, for your time.
I was hoping that someone have done what you described.
I would like to know if the "absolutely not" answer is an opinion or you did try to use a custom ribbon to restore functionality to access runtime. I am asking because I am half way through a 680 pages book on this subject and I know for sure that this is possible in many situations like print preview, filter, format text, import/export data etc. It is not clear yet if it will be possible for layout changes that I need.
Believe me, I am very well aware of the differences between full Access and runtime version. The database in question is created by me, it will be deployed in 6 locations and used by non tech-savvy users. So, report generators or full Access for those users are out of the question.
My solution so far: I have already a custom contextual ribbon for my report, with buttons to open/close the report and a split button to change views (report/design/print preview). As I stated before, it works with access runtime (blank report in design view, select 'invisible' text box then move). I could 'live' with this solution but I am searching for a more elegant one because 'we do these things not because they are easy, but because they are hard'.

I was hoping that someone have done what you described.

Click to expand...

I have (for forms) but it is very application specific and has to be designed into the application from the very beginning, not as an afterthought.

would like to know if the "absolutely not" answer is an opinion or you did try to use a custom ribbon to restore functionality to access runtime.

Click to expand...

not an opinion, its a fact. It is not a case of restoring functionality to runtime - it is not there in the first place. If you are the developer, you can write your own functionality to replace what is not in runtime - as per my original post, write your own editor.

typically you would have a 'editmode' Boolean and on control mouseover events, if it is true your would do something - perhaps change the cursor and then on a mouse down event, and enable the user to move the control, then store the change in a table on the mouse up event.

But you won't be able to add or delete controls (although you can have some standard unbound controls hidden until required)