The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
Passing values to the Add New Contact Account form
Posted: 18 Mar 06 7:49 PM
|
usa buy abortion pill abortion pill over the counter in usa
I'm stuck on this one...
From a Data Form I am launching the System:Add New Contact Account form using this code:
Dim objMyForm
Set objMyForm = Application.MainViews.Add("System:Add New Contact Account",0,False)
That works fine, but I'd really like to set a couple of the values on this form such as the Contact Name, Email and even the Address. Can't seem to figure how to do this - any code snippets will be greatly appreciated.
Thanks,
Rick |
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 18 Mar 06 8:32 PM
|
potency of naloxone and naltrexone naltrexone vs naloxone usmle website
Dim objMyForm
Set objMyForm = Application.MainViews.Add("System:Add New Contact Account",0,False)
call objMyForm.DetailsView.Script.InitializeForm.InitializeForm("ContactName", "Email", "Address1", "etc")
Good luck!
Timmus |
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 18 Mar 06 8:33 PM
|
Oooops. I guess I really liked my routine name and typed it twice 
Dim objMyForm
Set objMyForm = Application.MainViews.Add("System:Add New Contact Account",0,False)
call objMyForm.DetailsView.Script.InitializeForm("ContactName", "Email", "Address1", "etc")
|
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 20 Mar 06 10:32 AM
|
Within your calling code you can set default values as well.
Here is a code sample:
Dim objMyForm
Dim oDetail
Set objMyForm = Set oMainView = Application.MainViews.Add("System:Add New Contact Account", 0, False)
objMyForm.Height = 200
objMyForm.Width = 550
objMyForm.BorderStyle = 3
objMyForm.Caption = Application.Translator.Localize("Add New Company / Contact")
Set oDetail = oMainView.DetailsView
oDetail.txtEmail.Text = "sampleEmailAddress"
oDetail.txtAddress1.Text = "Address Line 1"
'You get the idea - any object on the form can be referenced as oDetail.
If objMyForm.ShowModal = mrOK Then
' Do something here - this is the OK button being pressed
End If
Set objMyForm = Nothing
Set oDetail = Nothing
|
|
|
| |
|
Re: Passing values to the Add New Contact Account form
Posted: 20 Mar 06 10:44 AM
|
fiogf49gjkf0d I have been doing a lot of traveling as of late - today is my recoup day so getting caught up on the more fun part of my job.
By the way I love the new forums and the other updates on the site. VERY NICE
Ted |
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 20 Mar 06 10:51 AM
|
fiogf49gjkf0d Personal preference but I recommend against accessing controls directly from outside scripts (code that is not "behind the form"). It makes tracking down errors a real nightmare for future developers. If the code is wrapped within a member local to the form, it is easy to see why deleting the txtAddress1 control has ramifications. Tracking down all the code that calls the add contact screen and removing the reference to txtAddress1 is much more work than simply updating the InitializeForm member.
All IMHO...
Timmus
|
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 20 Mar 06 11:50 AM
|
I completely agree with you Timmus. Things because really hairy, really fast when you change the controls on the form and not sure what you've broken from somewhere else.
However, I do avoid doing that as well, but it is still worth mentioning that it is possible as sometimes it opens eyes to things you can do knowing that the possibility is there (but also worth mentioning the warning as you have as well  ) |
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 20 Mar 06 11:58 AM
|
prednisolon og alkohol prednisolon bivirkninger halsbrand click
Its all a matter of "what makes sense". 
Timmus |
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 21 Mar 06 12:40 AM
|
InitializeForm is a nice script but you are correct when you say that wrapping every control in an Init() statement is a lot of extra cruft. You can abstract away the guts of it through classes or include scripts to strip each down to a miminal amount of code but it's still a nightmare, especially if you don't pass the correct number of parameters (takes 22 parameters? Woops, I only included 16).
Personally I do change form controls a lot because the naming convention is ancient. txtAddress1? textBoxAddressLine1 seems more elegant but you may run into size limits if you use something long like thisStringIsSuperLongBecauseIWantItToBeAndStuff. I've adopted camel case for all custom forms (and some base forms) and I've yet to run into a problem with size. If I do, trimming the name down isn't a difficult thing to do.
I don't abstract control code directly but any code that repeats among multiple forms gets refactored into a class. I have a number of classes I've been slowly molding since our 6.1 upgrade that keep growing as code becomes more complex. There is a downside to abstracting code away as mentioned: if you have a problem with what CALLS the code, you have to change every location that calls it. The most common of these is a parameter change in a routine. If you have a problem in the class itself, the cool part about that is when you fix the class, every form that calls it is fixed. These types of bugs are usually rare if you develop your abstractions well but sometimes you do have to play catchup between major versions if you're not careful. |
|
|
|
Re: Passing values to the Add New Contact Account form
Posted: 22 Mar 06 11:50 AM
|
where can i buy low dose naltrexone naltrexone buy online blog.birdcontrol.co.nz buy low dose naltrexone canada
An alternative is to make use of the Application.GlobalInfo collection and reference it in the Form_OnOpen event. A lot of people swear off globals and I try to avoid them myself. However, if you're dealing with a number of parameters and a lot of them are optional, it might make sense, as long as you use a naming convention that identifies the variables as arguments for a dialog, and destroy them as soon as the dialog uses them.
You mentioned that you use classes. Consider also creating a VBScript arguments class, where you can set various optional properties of an instance of this VBScript class during runtime and pass the class in either through the InitializeForm() script or through the GlobalInfo collection.
I do completely agree with Timmus with the recommendation not to modify controls from external scripts, although there are times when it might be necessary. I'm just not sure when those times are, though. |
|
|
|