 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Word / Programming / August 2005General Question About Userforms and Properties
Hi, I am using WORD 2000 and I have a general question about Userforms and Properties. Userform-1 displays a custom dialog, Userform-2. Userform-1 has to know which command button(s) were pressed in Userform-2. Arguments are "passed" between the forms by property statements. Userform-2 sets properties in Userform-1 by using the CallByName statement. Userform-1 object and property names set in Userform-2 via property statements. Has anybody had any problems using the above described scenario? That is, are there problems using property statements in Userforms and using the CallByName statement? It does seem to work but I would just like to know if there are any "gotchas". Thanks in advance for any help, advice and tips. Jerry Bodoff Two issues: first, CallByName is slow as hell. Second, it's bad programming practice: a called object shouldn't need any knowledge of its caller. Much simpler is for Userform2 to set set an internal property, which is read by UserForm1 -- -- In UserForm1 With new UserForm2 .Show Select Case .Result Case 1 ... end with -- In UserForm2 Private mResult as long 'Module-level variable Private Sub cmdOK_Click() 'Set the result value in the command button click events mResult = 1 End Sub 'Make the result available to the caller Public Property Get Result() as long Result = mResult End Property > Hi, > [quoted text clipped - 20 lines] > > Jerry Bodoff Hi Jezebel, First off let me say I am sorry about the original message formatting. I created the question in WORD and cut and paste. When I do this the formatting gets all screwy. I have to agree with you that passing properties back and forth is terrible and not good practice. I do not think your method will work ( unless I am missing something ). As far as I know Userform1 cannot read Userform2 properties since return to Userform1 is not made until Userform2 unloads. Therefore, the links are broken and an error message results. I solved the problem by associating a ClassModule with Form2. Form1 sets Class Module properties and the form is displayed in the module. Form2 currently has 1 property which is the ClassModule object ("handle"?). That way Form2 can communicate with the existing ClassModule. I am in the processing of getting rid of that assignment also. I am working on creating and passing a UserType to a Form2 method which would use the data to initialize the form. That way if I have a lot of initial data I only need 1 method instead of a bunch of properties. I really think the ClassModule is the way to go. Thanks for your tips and comments. It was appreciated and gave me the "spark" to create a ClassModule solution. Jerry Bodoff > Two issues: first, CallByName is slow as hell. Second, it's bad programming > practice: a called object shouldn't need any knowledge of its caller. [quoted text clipped - 50 lines] > > > > Jerry Bodoff > As far as I know Userform1 cannot read Userform2 > properties since return to Userform1 is not made until Userform2 unloads. The process is more subtle than this. It is sufficient for UserForm2 to be hidden to pass control back to UserForm1. That too is better programming practice: in classic object-oriented design, an object should never terminate itself -- that's the responsibility of the caller. Experiment with code along these lines -- In UserForm1 ------ Dim pForm as UserForm2 Set pForm = new UserForm2 .... at this point you can set and read properties in pForm pForm.Show ... at this point also you can set and read properties in pForm unload pForm Set pForm = nothing In UserForm2 ---- Sub cmdClose_Click() Me.Hide End Sub > Hi Jezebel, > [quoted text clipped - 87 lines] >> > >> > Jerry Bodoff Hi Jezebel, I took an approach similar to API's and dialogs. I created a "Dialog Structure" module which contains the structure Type definition and a Public definition. Form1 populates the structure by DlgData.Field and then shows Form2. Form2 does its thing and populates applicable structure fields. Form2, when done, "closes" itself and therefore Form1 is re-activated. A proper approach would be to create a Class Module and set properties and let the Class Module "read" and "write" structure data and start the form. As far as I know hiding Form2 does not create a return to Form1. A return is made when Form2 "shuts down". What you suggest is probably possible with modeless forms. All my forms are modal. Thanks for the help and discussion. It is always informative to see how other people approach a problem and one always learns from these discussions. Jerry Bodoff > > As far as I know Userform1 cannot read Userform2 > > properties since return to Userform1 is not made until Userform2 unloads. [quoted text clipped - 117 lines] > >> > > >> > Jerry Bodoff Hi Jezebel, I have to apologize. In my previous answer I was unaware that Hide re-activated the calling form. As I said we are always learning. To do things properly I am creating a ClassModule to "read" and "write" the data structure. Thanks. Jerry Bodoff > > As far as I know Userform1 cannot read Userform2 > > properties since return to Userform1 is not made until Userform2 unloads. [quoted text clipped - 117 lines] > >> > > >> > Jerry Bodoff Your class module approach is certainly thorough, but it seems excessive to me. It's worth noting that a form module is just a special kind of class module anyway. It has most of the properties and behaviours of an ordinary class module, with the additional graphic component. If you never Show the form, it behaves exactly like any other class module. So rather than populating your class, it might be simpler just to add property functions to the form itself. Occam's razor and all that. > Hi Jezebel, > [quoted text clipped - 139 lines] >> >> > >> >> > Jerry Bodoff Hi Jezebel, Thanks for all your help. I decided to use the Class Module because I am doing a bit of data validation in it and I have a few Custom Dialogs that will be processed by the same module. They all use the same structure and I have about 10 forms that will call it. Jerry Bodoff > Your class module approach is certainly thorough, but it seems excessive to > me. It's worth noting that a form module is just a special kind of class [quoted text clipped - 148 lines] > >> >> > > >> >> > Jerry Bodoff |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.