![]() |
Planning a complex meeting request form and wishing some advice
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 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 FormView 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 |
Planning a complex meeting request form and wishing some advice
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. -- 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: 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 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 FormView 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 |
Planning a complex meeting request form and wishing some advic
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. |
Planning a complex meeting request form and wishing some advic
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. |
All times are GMT +1. The time now is 12:00 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 2.4.0
Copyright ©2004-2006 OutlookBanter.com