Planning a complex meeting request form and wishing some advice

G

Guest

I have taken on the job of creating a custom form that incorporates a
paper-based form and I would like some advice before I start on the form. I
intend to purchase an Outlook coding book, but am finding it difficult to
find one in the brick&mortar tech stores in my area. I need to use an online
store to purchase one. Only then will I start the coding for the form, but
until then I would like to create the basic layout, and later create the
code. Please excuse the rambling/backstory below, it helps set the scene.

Sue Mosher gave me some excellent advice and help with a problem I was
having with printing a form to Word. I have limited scripting experience with
Excel and Access (and now Outlook).
What I am wanting to create is a custom Meeting Request form. The
Appointment and Scheduling tabs would not be touched. I will be creating two
new tabs and using User-Created Fields to recreate what is on the paper-based
system. When the meeting request using this custom form is sent, recipients
would be able to read the fields on the other two new tabs, as well as the
main Appointment tab. If required the information on the Appointment tab, as
well as the two new tabs can be printed to a Word document, and if required
saved to a Word document with the information in the form.

That is what I would like the custom Meeting Request form to do. I was
reading some of the articles at OutlookCode.com and came across a few
interesting tidbits and was hoping for some advice.
When I have created custom forms in the past, I would create the new fields
in the form that required it. But in one of the articles I noticed that it
suggested that a new subfolder should be created, and in the new folder,
access the Field Chooser and create the new fields there.

At the current point I am seeing this project be ongoing, and not completed
in one session. Would it be best to create an .oft and store it on my
computer, or after each addition to the form, publish it and save it in the
new folder? I know that code can only be run in published forms, not stored
..ofts.

In regard to code, I currently see three sections of code required - a
command button to print what is on the Appointment tab, and the two created
tabs; a command button to save the information to a Word document (via the
template that is used to print the form) and it prompts the user for the
location of the saved document; and lastly some code that would make a new
field visible only after the user has started typing in the field above it
(more on this below).

The last bit of code is required as in a few different sections of the
paper-based system there is room for multiple entries, dependant upon how
many the user wants to use. So I am envisioning making in some areas 10 rows
available, and in other sections up to 20 rows available. But I dont want all
of the rows to be visible at once. So what I would like (as I know it can be
done in Access) is to have the first row visible, and when the user starts
typing in the first row, the second row of fields become visible. If they use
the second row, the third becomes visible, and so forth, until the last row
is entered and up comes a Message Box informing the user that there is no
more fields available.
Is the above possible in Outlook custom forms?

Last question: When I have created code in a custom Outlook form in the
past, I have used Form>View Code, which brings up a new window similar to
Notepad, in which all code is manually entered. Is it possible when creating
a new custom form, to access the Visual Studio Window? This would make life
easier for creating the Subs for the required control and action.

I hope the above makes sense, and I think a lot of my questions would be
answered once I get my hands on an Outlook Programming manual, but until then
I would like to plan what the custom form will do, create the layout, and
only after reading the manual will I attempt the code. Any help, suggestions
and input is appreciated.

Duane
 
G

Guest

Hi Duane. Continue to create custom fields in the form as you are doing -
creating them in a sub-folder of the folder where the form is published makes
no sense at all - I'm not sure where you saw that approach being suggested.

If you want to ensure you don't lose your work, I suggest that after you
publish your form you export it as an .fdm file and version it in your source
code control system if you use one. Also copy and paste the code behind your
form into Notepad and save .txt files of the code separately and version
those as well. I've been victimized in the past by the code being completely
removed from a published form due to corruption.

As for the optional/on-demand sections of controls you are hoping to use,
this would be ugly to implement. Hiding and showing would involve judicious
positioning of the controls - a mathematical headache - or leaving vast gaps
in the UI if you don't bother moving the controls at all. I suggest just
enabling/disabling controls, or grouping them onto separate pages.

Finally, I'm afraid we are stuck with the Notepad style code editing for
custom forms, no Visual Studio - UNLESS you are building Form Regions with
Outlook 2007.
 
G

Guest

Eric, thanks for the reply and info. Responses to specific sections below.

Eric Legault said:
Hi Duane. Continue to create custom fields in the form as you are doing -
creating them in a sub-folder of the folder where the form is published makes
no sense at all - I'm not sure where you saw that approach being suggested.

If you want to ensure you don't lose your work, I suggest that after you
publish your form you export it as an .fdm file and version it in your source
code control system if you use one. Also copy and paste the code behind your
form into Notepad and save .txt files of the code separately and version
those as well. I've been victimized in the past by the code being completely
removed from a published form due to corruption.

I have never worked with Exchange, so I am not familiar with the .fdm
extension, but a Google search informs me of what it is, it just doesn't tell
me how to export as .fdm (unless you can write the extension yourself when
you File>Save As).
Thankfully I have already being doing the copy/paste code into txt files as
I thought the corruption might happen.

As for the optional/on-demand sections of controls you are hoping to use,
this would be ugly to implement. Hiding and showing would involve judicious
positioning of the controls - a mathematical headache - or leaving vast gaps
in the UI if you don't bother moving the controls at all. I suggest just
enabling/disabling controls, or grouping them onto separate pages.

I had intended to leave vast gaps of form and then having the controls
appear as required, but I definitely prefer the suggestion of
enabling/disabling the controls. I dont want to use too many pages as this
would be confusing, and does not follow the paper-based process works.
Finally, I'm afraid we are stuck with the Notepad style code editing for
custom forms, no Visual Studio - UNLESS you are building Form Regions with
Outlook 2007.

Work is not ready to move to Office 2007 as of yet, thus if I made them at
home (where I am using Office 07) they would not be backward compatible with
Outlook 2003 that is still being used at work.

Question in regard to coding into the View Code box: I am going to need at
least three sections of code - 1 for printing, 1 for saving, and 1 for the
enabling/disabling. Does it matter which order I type the code into the View
Code area? What I mean is does the order of Sub cmdPrint_Click() appearing
above or below Sub cmdSave_Click() matter?
The reason I ask is that after I have done the layout, I will create the
print to Word code, as that is the one I am familiar with and I want to make
sure it works, and when I am ready for the saving to Word and
enabling/disabling will it matter if that is written after the printing code?
Personally I dont think it matters, as it looks for the Sub no matter where
it is, but I am just a beginner and still getting used to this.

Again thank you for the help. Much appreciated.
 
G

Guest

Saving as an .fdm has nothing to do with Exchange BTW. You can publish forms
without Exchange no problem (although Exchange offers a central library for
publishing). You can save an .fdm file from the Forms Manager dialog;
right-click the folder where the form is published and select Properties,
then click the Manage button on the Forms tab (for the Personal Forms library
you can access it via Tools -> Options -> Other -> Advanced Options -> Custom
Forms -> Manage Forms). Select the published form on the right and choose
Save As, and select .fdm from the file type dropdown.

You CAN create forms in Outlook 2007 and they will work fine in Outlook
2003. It is however best practice to design it using the version that will
use it the most.

You're right - the order of procedures does not matter in the code editor.

--
Eric Legault - Outlook MVP, MCDBA, MCTS (SharePoint programming, etc.)
Try Picture Attachments Wizard for Outlook:
http://www.collaborativeinnovations.ca
Blog: http://blogs.officezealot.com/legault/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top