Administrative Help Needed (Word 2007)

I've recently posted a question at the MS Word forums at Microsoft's site. Just because you never know where you'll find help, I'm posting it here. At a games site. Where people talk about gaming. I am not a crackpot:

Greetings community members,

I am in the process of updating some very old institutional templates using Word 2007's improved functionality. There is a lot to like in the new ways that you can control access to the forms. Wherever possible, I am using the Controls (found in the Developer ribbon).

Basic Facts: I'm assembling a large (15-20 pages) DOTX document that is rife with fields that require entry by the user. The document contains Plain Text fields, Rich Text fields, Numerous Drop-Down boxes, and a few Calendar Picker fields. Eventually, I would like to Protect the document against all formatting changes except the field-data.

ISSUE #1 : MOVING WITH THE TAB KEY THROUGH RICH TEXT FIELDS

The beginning of my document has a number of blank Plain Text fields that require basic facts like contact information and what-not. I can enter data, hit the TAB key, then enter more data, just fine. However, once I move past those values and on to the Rich Text fields, the TAB key ceases to "move me along" the fields, and rather behaves as you would expect the TAB key to outside a form-field.

I'm sure this is intentional (these *are* rich text settings, right?), but even so - is there a way to cause the DOTX file to treat the field movement the way I want it to? Failing that, is there at least a way to stop the field itself from getting "pushed" along the default tab stops? I mention THAT because some of these fields will not be filled out (they are entirely
optional), so the users will naturally hit the TAB key and it won't behave the way they've come to expect it.

It is vital that I retain the formatting options, as the large amounts of data entered into some of these fields will need to have italics and other formatting options, though, ironically, not tabs.

ISSUE #2 : MOUSE-OVER TEXT POP-UPS

Within Microsoft Excel, you can "Insert Comment" beautifully. If I mouse over the cell, a non-printable text field will pop-up. I need to replicate this functionality within Microsoft Word. If I can't exactly get what I want (a question-mark image that, when moused over, informs the user of template information), I would certainly live with a way to create NON-PRINTABLE text. It makes the WYSIWYG nature of Word a lot more difficult, but at least I could enter these elements at the END, after I've already figured out layout issues.

ISSUE #3 : DYNAMICALLY ADDING ROWS TO TABLES

This document has a few tables that may (or may not) need to be filled out, depending upon the user's needs. As this will ultimately be protected against everything except form field entries, it means that I have to create a number of rows (with fields within) that may or (more likely) may not be used.

What I'd RATHER do is create a way to click a button and add a row (with accompanying fields). However, this strikes me as the sort of thing that may be out of the core Word functionality, which is why it's #3 on the list.

CLOSING SUMMARY

These are the outstanding issues that I haven't yet resolved. I'd appreciate any help you community members can offer.

Thanks in advance.

As you've found, it doesn't take much to get beyond what you can realisticly do in Word before things get messy. I struggle with doing pretty simple things in Word, but loves me some Excel!

Anyway, this may be beyond what you're willing or able to do, but you may want to check out WPF & FlowDocuments. You can build a XBAP browser app that displays a FlowDocument and then you can easily save, print or whatever you need from there. Again, this is more of a development type suggestion and would require Visual Studio 2008 (Express editions are free), but depending on your goals and needs, it sure sounds like it would suit what you're trying to accomplish.

Another option may be InfoPath. I don't have much experience in using it, but again, it seems suited to large forms used to gather loads of information.

Hi TexasRay,

Thanks for your thoughts. I'm not a coder and I'm quite positive my employer will stop me if I try to spend too much time on that sort of thing. However, I am hoping (someday) to learn more about InfoPath. I am aware that it is a fairly feature-rich toolset, but the learning curve seems a bit higher than Word.

In the case of this Word document that I'm putting together, I definitely need it to be in Word format (and not some alternate route) because of its large size. Also, everyone's been conditioned to use Word for all these matters. It's a scientific form that requires vast amounts of data to be inserted into the fields, meaning that the content all gets shifted down as more is entered.

That part of this whole thing (downward shifting content) is why I can't just create a PDF form, since PDF contents don't shift very easily. Anyhow, I'm continuing to learn more as I troubleshoot. To see a more detailed look at what I'm learning/resolving, hit this link.

Thanks again, Ray.

Sounds like you're heading towards working things out. For the "downward shifting content", it sounds like Excel may be better suited, but not sure how you'd merge the word docs into Excel or vice versa. Also, don't let the macro/code stuff intimdate you...Office is great about building code for you when you record macros and you can use that to easily figgure out what you need to do. Plus, whats the worst that can happen if you bung something up? Just work off off a copy of the master doc until you get it figgured out.

As a developer, anytime I see or hear of people using massive word docs, excel sheets or paper forms to capture data, alarms start going off in my head and my OCD kicks in to where I have to streamline/automate things to get off of paper and even tons of digital forms and get the data into a database and have websites/applications capture the data. Your situation would certainly qualify! If you get to that point and woud like some help or advice, feel free to gve me a shout.

-Ray!!

Thanks again for your thoughts! Sadly, I just don't have the latitude to be able to create a better method of capturing this information. These forms have to be filled out and physically signed for and changing the basic nature of the info-capture just won't be tolerated. (We have lots of old fashioned folks and limited time to implement besides)

What I am interested in is finding some kind of community where such work could be subcontracted out. I can't imagine that something hasn't popped up. I would be very happy to pay someone to make the tiny mods I need to get the form to behave. Do you know of such a place? It's going to be this week's little research project.

A LONG LONG time ago, in the 1993 timeframe, I did something a lot like what you're doing now, but with Access 2.0. That wasn't a very good database, but I didn't know that at the time.

What I ended up doing was this: most of the fields were Access fields that mapped straight into the database, but then I wrote code on virtually every damn field to get the keyboard working right. I hated that you couldn't tab through in sensible order, so I ended up adding code to essentially every field in the form so that tab went to the next field, and shift-tab went to the prior field, where _I_ was defining what prior and next were, instead of Access. This got hairy when fields were subtables -- table controls had to be smart enough to know if they were the first or the last record, in which case they needed to tab out of the subfield completely, but if they were midpoint, they needed to tab to the next row in the subfield.

This was a system to do roofing contracts; the roofing contracts were all done as templates, which were actually each separate embedded Word documents. (I embedded whole Word docs directly as fields in the database.) The Word documents started out as Word tables with all the possible paragraphs, and then it popped up a dialog box with checkboxes -- I checked what I wanted for a particular contract. It then deleted every paragraph I DIDN'T want, and then converted the tables to normal text, so that it flowed like a normal document would.

Then, come time to print the contract out, the printable form pulled mostly fields from Access, embedded the Word document with the printed text, and it even autoscaled it if it was too large.

From my experience in the 1993 timeframe, I'd be willing to bet you can do exactly what you want if you use Access as your primary front end. I think it even has rich text fields now, which it didn't have way back when. I'm sure it's a lot smarter about moving around from keystrokes now than it used to be, and things like auto-growing tables were dirt-simple even in 1993.

You probably would want to tie Access into a real SQL server, instead of using MDB files like I was forced to on my very limited budget back then, but I bet you'd be able to do just about anything you need with it. But you'll have to learn some database design. The old Access manuals were the best part of the package; they were better at explaining database normalization than any other source I've ever found. I spent several weeks just studying intensely before I even started, and even then I felt rushed.

Basically, the reason Access may be what you want is because you define fields, can lay them out visually however you want, and can attach very sophisticated code to run in those fields. Then you can output your data with a different form, intended for printing, so you can separate the data entry from the reproduction.

I'm not sure whether you're actually doing database work gussied up as a sophisticated form, or if it's just a form, but Access would work fine in both cases. Even if your database has just one entry in it per person, it's still a database.

Malor, I love this idea. Frankly, it's what I'd prefer, since we have an Access guru on staff that does stuff like this. However, the scientists that I work for simply won't accept it. They want a document that they can work on for the three weeks it takes to get the form filled out. Getting them to use a database front end would be akin to requesting that HR use a few horses to tear my arms and legs off for me.

However, I am going to forward an edited version of your comment to someone that should keep it in mind. If we ever get clearance for an overhaul of the way we do things, I'll shoot for your idea.

Well, you can make it a standalone application -- it'll work just like a Word document, more or less. Parts of it may even BE Word documents. You're just, presumably, storing one record in a local database, an MDB file sitting on their hard drive. It's the same MDB file that stores the forms -- the whole shebang comes packaged in one file.

The only real difference is that edits go live instantly -- if they change something, it's changed. No revision history unless you create it with multiple records in the database and a pretty fair bit of glue code to make it work.

Basically, you need highly flexible forms with a lot of intelligence, and you don't have the budget or possibly expertise to do a custom program. This is THE BEST use case for Access I know.

Like Malor said, the sooner you got things into a database (preferably centralized vs several .mdb's floating around one or more networks), the better - worlds of options (reporting, editing, etc) open up once you do that.

I'm curious what they do with these docs after they're filled out? I would think that anything that required so much time and effort to enter would want to be re-visited at some point - or compared to other versions of the form. How is that done?

It sounds like scientists are very much like lawyers. I was amazed at how much the lawyers I worked for refused to adapt to changing technology even when you beat them over the head with the benefits of such a move. I had to spend MONTHS pitching a move to CD-ROM based legal libraries so that they could look things up via search vs hunting for the right book. Once we got them on board, they loved it, but man - it was a hard sell.

A central database would be WAY WAY WAY better -- but you can do that as a separate step after you get them used to Access and a local DB. Just have them hand in their MDB, and you manually import it into the database, or set up a macro to do it.

If they always work on the network, rather than doing it offline, converting them from there to a live database will be absolutely trivial. It won't even feel any different to them, except that they can then read their data from any station on the network. You just connect the data tables to the SQL server instead of the local MDB file. Everything keeps working the same, and all the data shows up like magic in Central Command.