|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
[VB6] Passing the variable value to the form?should call up a new form. Form should 'behave' depending on the parametar beeing passed to it. So, if I have, for instance: Sub mnuNewDocument_Click() ' From here we do 'new form' Const NEW_FORM = 1 Load MyForm MyForm.DoInitialization NEW_FORM MyForm.Show End Sub Now, I leave the OnLoad event empty, and I handle all the initializations within the DoInitialization sub in the MyForm. Is there another way of passing the arguments to the new form? Mike -- "I can do it quick. I can do it cheap. I can do it well. Pick any two." Mario Splivalo mspli***@jagor.srce.hr Never seen the 'OnLoad' event but try this:
New std exe and add a form 'Form1 Option Explicit Private Sub Form_Load() Dim frm As Form Set frm = New Form2 frm.TypeInit = 1 frm.Show vbModal Set frm = Nothing End Sub 'Form2 Option Explicit Public TypeInit As Long 'this could also be a Public Property Private Sub Form_Load() DoInitialization End Sub Private Sub DoInitialization() Select Case TypeInit Case 0 BackColor = vbWhite 'or whatever Case 1 BackColor = vbBlue End Select End Sub Show quoteHide quote "Mario Splivalo" <m***@fly.srk.fer.hr> wrote in message news:slrndj2m1h.ed5.majk@fly.srk.fer.hr... > How whould one handle that? Let's say we have a menu callback function wich > should call up a new form. Form should 'behave' depending on the parametar > beeing passed to it. > > So, if I have, for instance: > > Sub mnuNewDocument_Click() > ' From here we do 'new form' > > Const NEW_FORM = 1 > > Load MyForm > MyForm.DoInitialization NEW_FORM > MyForm.Show > End Sub > > Now, I leave the OnLoad event empty, and I handle all the initializations > within the DoInitialization sub in the MyForm. > > Is there another way of passing the arguments to the new form? > > > Mike > -- > "I can do it quick. I can do it cheap. I can do it well. Pick any two." > > Mario Splivalo > mspli***@jagor.srce.hr On 2005-09-21, Norm Cook <normcookNOSPAM@cableone.net> wrote:
> Never seen the 'OnLoad' event but try this: Acutally, I ment Form_Load() :)Show quoteHide quote > New std exe and add a form This is no good. Form_Load event will occur as soon as you do this:> > 'Form1 > Option Explicit > Private Sub Form_Load() > Dim frm As Form > Set frm = New Form2 > frm.TypeInit = 1 > frm.Show vbModal > Set frm = Nothing > End Sub > > 'Form2 > Option Explicit > Public TypeInit As Long 'this could also be a Public Property > Private Sub Form_Load() > DoInitialization > End Sub > Private Sub DoInitialization() > Select Case TypeInit > Case 0 > BackColor = vbWhite 'or whatever > Case 1 > BackColor = vbBlue > End Select > End Sub Set frm=New Form2 So, Form_Load will do the DoInitialization(), when the TypeInit has not been set. Mike -- "I can do it quick. I can do it cheap. I can do it well. Pick any two." Mario Splivalo mspli***@jagor.srce.hr
Show quote
Hide quote
"Mario Splivalo" <m***@fly.srk.fer.hr> wrote in message Actually, that's incorrect. Form_Load won't fire just by setting a property news:slrndj2o29.l2f.majk@fly.srk.fer.hr... > > This is no good. Form_Load event will occur as soon as you do this: > Set frm=New Form2 > > So, Form_Load will do the DoInitialization(), when the TypeInit has not > been > set. > > Mike > -- > "I can do it quick. I can do it cheap. I can do it well. Pick any two." > > Mario Splivalo > mspli***@jagor.srce.hr of the form. Form_Initialize will but Load won't. Paste this into a new, 2 form project for proof. '==========Form1 Code Option Explicit Private Sub Form_Click() Dim f As Form2 Debug.Assert False 'single step from here Set f = New Form2 f.Test = 12345 f.Show End Sub '==========Form2 Code Option Explicit Private miTest As Integer Public Property Get Test() As Integer Test = miTest End Property Public Property Let Test(ByVal Setting As Integer) miTest = Setting End Property Private Sub Form_Load() Debug.Print "'Form2:Form_Load", Timer End Sub '========== -- Ken Halter - MS-MVP-VB - http://www.vbsight.com DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Please keep all discussions in the groups..
Show quote
Hide quote
"Mario Splivalo" <m***@fly.srk.fer.hr> wrote Isn't that method working for you? When asked, is there another method> How whould one handle that? Let's say we have a menu callback function wich > should call up a new form. Form should 'behave' depending on the parametar > beeing passed to it. > > So, if I have, for instance: > > Sub mnuNewDocument_Click() > ' From here we do 'new form' > > Const NEW_FORM = 1 > > Load MyForm > MyForm.DoInitialization NEW_FORM > MyForm.Show > End Sub > > Now, I leave the OnLoad event empty, and I handle all the initializations > within the DoInitialization sub in the MyForm. > > Is there another way of passing the arguments to the new form? of 'passing the arguments' your only other option (instead of the Sub) is a Function, but that is pretty much the same idea. You can give that form properties to set, if that will help, but passing in arguments makes for a single call to the form. (Your Show method could be called from DoInitialization to make it a one call event) What does your current method lack, that causes you to look for another way? LFS On 2005-09-21, Larry Serflaten <serfla***@usinternet.com> wrote:
> Lacks nothing, I was just seeking other options. The thng is that I> Isn't that method working for you? When asked, is there another method > of 'passing the arguments' your only other option (instead of the Sub) is > a Function, but that is pretty much the same idea. > > You can give that form properties to set, if that will help, but passing in > arguments makes for a single call to the form. (Your Show method could > be called from DoInitialization to make it a one call event) > > What does your current method lack, that causes you to look for another > way? inherited some code to mantain where the wise-guy did passing the variables to the form via the .tmp file on the filesystem! :) Thanks for your reply, it works fine that way. FormLoad is empty, so is FormInitialize, I instance the new form via the Dim f As New OrigForm, and have public sub that does the initialization and does the Me.Show. Mike -- "I can do it quick. I can do it cheap. I can do it well. Pick any two." Mario Splivalo mspli***@jagor.srce.hr
Show quote
Hide quote
"Mario Splivalo" <m***@fly.srk.fer.hr> wrote in message Not really. Passing data to the form via properties or a custom method and news:slrndj2m1h.ed5.majk@fly.srk.fer.hr... > How whould one handle that? Let's say we have a menu callback function > wich > should call up a new form. Form should 'behave' depending on the parametar > beeing passed to it. > > So, if I have, for instance: > > Sub mnuNewDocument_Click() > ' From here we do 'new form' > > Const NEW_FORM = 1 > > Load MyForm > MyForm.DoInitialization NEW_FORM > MyForm.Show > End Sub > > Now, I leave the OnLoad event empty, and I handle all the initializations > within the DoInitialization sub in the MyForm. > > Is there another way of passing the arguments to the new form? then calling an initialization method is pretty much the standard way of setting up a form before showing it. It also generally means that Form_Load is left mostly empty. Mario Splivalo wrote:
> How whould one handle that? Let's say we have a menu callback Take a look at http://vb.mvps.org/samples/Splash for my recommendation. In short,> function wich should call up a new form. Form should 'behave' > depending on the parametar beeing passed to it. since VB4, the best method is to: * Add your own custom properties to the form. * Create a new instance of the form. * Set the properties appropriately. * Show the form. * Configure the form appropriately during Form_Load. Be sure that your property Set routines do nothing but cache the value. If they reference any form or control properties, that will trigger a premature Form_Load. Later... Karl
Show quote
Hide quote
"Karl E. Peterson" <k***@mvps.org> wrote How is adding properties better than passing in parameters to a> Mario Splivalo wrote: > > How whould one handle that? Let's say we have a menu callback > > function wich should call up a new form. Form should 'behave' > > depending on the parametar beeing passed to it. > > Take a look at http://vb.mvps.org/samples/Splash for my recommendation. In short, > since VB4, the best method is to: > > * Add your own custom properties to the form. > * Create a new instance of the form. > * Set the properties appropriately. > * Show the form. > * Configure the form appropriately during Form_Load. public routine? IOW, why is using properties the "best" method? It just seems to me that adding public properties for several options is more effort and code than easily passing in a few values to some public method.... Consider also that a call will list all the needed options as parameters to the methods, where setting some number of properties may be prone to failing to set a needed property. ??? LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in message Good point Larry. Nearly all of my subforms contain the following:news:upyWl1uvFHA.3720@TK2MSFTNGP14.phx.gbl... > > "Karl E. Peterson" <k***@mvps.org> wrote > > Mario Splivalo wrote: > > > How whould one handle that? Let's say we have a menu callback > > > function wich should call up a new form. Form should 'behave' > > > depending on the parametar beeing passed to it. > > > > Take a look at http://vb.mvps.org/samples/Splash for my recommendation. In short, > > since VB4, the best method is to: > > > > * Add your own custom properties to the form. > > * Create a new instance of the form. > > * Set the properties appropriately. > > * Show the form. > > * Configure the form appropriately during Form_Load. > > > How is adding properties better than passing in parameters to a > public routine? IOW, why is using properties the "best" method? > > It just seems to me that adding public properties for several options > is more effort and code than easily passing in a few values to some > public method.... > > Consider also that a call will list all the needed options as parameters > to the methods, where setting some number of properties may be > prone to failing to set a needed property. > > ??? > LFS Private m_Result As VbMsgBoxResult ' Local module level vars here Private Sub Form_Load() m_Result = vbCancel ' m_Result set to other values elsewhere End Sub Public Function Display(<args passed by Ref>) As VbMsgBoxResult ' Set local variables = args here Me.Show vbModal ' Set args = local variables here Display = m_Result End Function The code seems to work fine but I'm wondering if using properties is a better way. Jim Edgar Hi Jim --
Show quoteHide quote > Good point Larry. Nearly all of my subforms contain the following: Nearly all mine contain code like this:> > Private m_Result As VbMsgBoxResult > ' Local module level vars here > > Private Sub Form_Load() > m_Result = vbCancel > ' m_Result set to other values elsewhere > End Sub > > Public Function Display(<args passed by Ref>) As VbMsgBoxResult > ' Set local variables = args here > Me.Show vbModal > ' Set args = local variables here > Display = m_Result > End Function > > The code seems to work fine but I'm wondering if using properties is a > better way. Public Property Get Cancelled() As Boolean Cancelled = m_Cancelled End Property Public Property Get Result() As Boolean Result = m_Result End Property Private Sub cmdCancel_Click() ' User initiated cancel! m_Cancelled = True Me.Hide End Sub Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer) ' If user clicked X, just set Cancel flag and hide. If UnloadMode = vbFormControlMenu Then m_Cancelled = True Cancel = True Me.Hide End If End Sub In addition to other properties that are used to configure the dialog, and/or read what the user did with it. Later... Karl Larry Serflaten wrote:
Show quoteHide quote > "Karl E. Peterson" <k***@mvps.org> wrote Hmmmm, maybe it's just my style? I guess, as often (if note more) than not, I query>> Mario Splivalo wrote: >>> How whould one handle that? Let's say we have a menu callback >>> function wich should call up a new form. Form should 'behave' >>> depending on the parametar beeing passed to it. >> >> Take a look at http://vb.mvps.org/samples/Splash for my >> recommendation. In short, since VB4, the best method is to: >> >> * Add your own custom properties to the form. >> * Create a new instance of the form. >> * Set the properties appropriately. >> * Show the form. >> * Configure the form appropriately during Form_Load. > > How is adding properties better than passing in parameters to a > public routine? IOW, why is using properties the "best" method? the properties again after the form has been hidden, to see what action(s) the user took. I like to work with the two-way street. It was an evolution of thought, though, I'll grant that. In VB4HT, I did what you suggest, and used separate Get/Set subroutines -- see 2.10 on http://vb.mvps.org/vb4ht/contents.asp > It just seems to me that adding public properties for several options Yep, it sure could be.> is more effort and code than easily passing in a few values to some > public method.... > Consider also that a call will list all the needed options as Right. YMMV.> parameters to the methods, where setting some number of properties > may be prone to failing to set a needed property. > > ??? 
Other interesting topics
Fluctuation of printer alignment
Database and report question Newbie: How to extract year from a Date object VB6 : Attach Event Handlers to Dynamically Generated Controls msgbox problem How can i make sure List all jpg files from folder (loop problem) Random first random number delete Missing File Export Template in VB.NET |
|||||||||||||||||||||||
