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/


"Duane Nutley" wrote:

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

"Eric Legault [MVP - Outlook]" wrote:

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 FileSave 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.