OT How much knowledge is enough?

[salad]

If one looks at job listings one will read the requirements of for it;
..Net, SQL, C#, etc.

How much skill, if years experience in the discipline isn't listed, is
needed. Could one simply get the C# program, read a book on it, do a
"Hello World" program, and feel comfortable on the topic and apply for
the job?

How much knowlecge is enough, if you've got a developer background, on a
new language or subject to go for it?

[Wayne Gillespie]

On Fri, 11 Aug 2006 22:09:48 GMT, Lyle Fairfield <ly***********@ aim.comwrote:

>"David W. Fenton" <XX*******@dfen ton.com.invalid wrote in
news:Xn******* *************** ************@12 7.0.0.1:

>But the drawback of that approach is that it's limited to forms not
opened modally.

I think this is not so, as I previously explained.

I pass values to and set properties in modal forms all the time without any
problems.
Wayne Gillespie
Gosford NSW Australia

[Larry Linson]

The Split statement, or one of the multitude of Split functions documented
in this newsgroup before the statement was included in VBA, has worked
nicely for me when using OpenArgs -- but I am usually passing just one item,
so even that is not often needed.

I don't have any particular gripe about defining and using properties, but
it does seem to me to entail extra work, most of the time.

Larry Linson
Microsoft Access MVP
"David W. Fenton" <XX*******@dfen ton.com.invalid wrote in message
news:Xn******** *************** ***********@127 .0.0.1...

"Larry Linson" <bo*****@localh ost.notwrote in
news:vCSCg.8609 4$Lh4.31865@trn ddc02:

>"Lyle Fairfield" <ly***********@ aim.comwrote

I guess this explains why I am unemployed.

Possibly, if you sought subcontract work from my colleague. <GRIN>

What is the advantage of creating and using a custom property to
pass information, versus using the supplied-with-the-product,
builtin OpenArgs property?

Well, for one, it makes it much neater to pass multiple values.
Second, by setting the values themselves, you can trigger actions
based on those (just as you can in any class module custom
property).

But the drawback of that approach is that it's limited to forms not
opened modally. I don't have too many of those, so I use standalone
data structures for passing information.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Larry Linson" <bo*****@localh ost.notwrote in
news:qsdDg.1867 $5M.1464@trnddc 02:

The Split statement, or one of the multitude of Split functions
documented in this newsgroup before the statement was included in
VBA, has worked nicely for me when using OpenArgs -- but I am
usually passing just one item, so even that is not often needed.

But there is no data type validation until you get into the form.

I don't have any particular gripe about defining and using
properties, but it does seem to me to entail extra work, most of
the time.

With custom properties, you can easily handle data type validation.

With Split() you'd have to put your data validation in the code that
parses the input.

You wouldn't write a function/sub that you pass a single string
argument and then parse it in the function/sub -- you'd use
individual parameters.

This is another reason why I prefer a standalone class module,
because then you'd get compile time data type checking.

On the other hand, if you could pass an array or a collection or a
custom type through OpenArgs, I wouldn't have a problem. With arrays
or collections, you'd still have to check the data types, but it
would be a very neat way to pass multiple values.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Wayne Gillespie <be*****@NOhotm ailSPAM.com.auw rote in
news:f7******** *************** *********@4ax.c om:

On Fri, 11 Aug 2006 22:09:48 GMT, Lyle Fairfield
<ly***********@ aim.comwrote:

>>"David W. Fenton" <XX*******@dfen ton.com.invalid wrote in
news:Xn****** *************** *************@1 27.0.0.1:

>>But the drawback of that approach is that it's limited to forms
not opened modally.

I think this is not so, as I previously explained.

I pass values to and set properties in modal forms all the time
without any problems.

You pass values to modal forms opened with acDialog? As in this:

DoCmd.OpenForm "dlgMyDialo g", , , , , acDialog
Forms!dlgMyDial og.MyProperty = "Foo"

How exactly does that work? Code pauses at the DoCmd.OpenForm line
and so the things you set won't be set when the user gets control of
the dialog.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Lyle Fairfield <ly***********@ aim.comwrote in
news:Xn******** *************** **********@216. 221.81.119:

"David W. Fenton" <XX*******@dfen ton.com.invalid wrote in
news:Xn******** *************** ***********@127 .0.0.1:

>But the drawback of that approach is that it's limited to forms
not opened modally.

I think this is not so, as I previously explained.

How, exactly, do you usefully set values/properties of a form opened
by this code:

DoCmd.OpenForm "dlgMyDailo g", , , , , acDialog

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Lyle Fairfield]

David W. Fenton wrote:

How, exactly, do you usefully set values/properties of a form opened
by this code:

DoCmd.OpenForm "dlgMyDailo g", , , , , acDialog

When you use this method you don't use that code:

Public Sub OpenForm1()
With Form_form1
.Modal = True
.Visible = True
.Blah = "Wrong"
End With
End Sub

The form is open.
The form is modal.
The form is visible.
The form's property("Blah" ) = "Wrong"

Larry is confused in thinking that this setting of a custom property
has something to do with the method. It does not. It was simply an
example of how one might pass information to a form when opening it by
using this method. One could have set or let the value of any writable
control, property of the form, or run any of its public procedures.

If Form1 has

Public Sub ShowaMessage()
MsgBox "Message"
End Sub

Then Form_Form1.Show aMessage displays "Message" whether or not the form
is modal.

My recommendation is that the form's instance be created with a pointer
as we would deal with any object as in (air code)

Dim frm as Form_Form1
Set frm = New Form_Form1
frm.ShowaMessag e
Set frm = Nothing.

What we have is something similar to a class. But with this "class"
there is always a default instance available to us by using Form_Form1.
And this "class" has it's own GUI (the visible form). We can use this
syntax to create multiple instances of our form>

Sub tempasdf()
Dim aFrm(0 To 9) As Form_form1
Dim z As Long
For z = 0 To 9
Set aFrm(z) = New Form_form1
aFrm(z).Caption = z
Next z
Erase aFrm
End Sub
.....

Erase aFrm ... presto ... all our instances are closed and their
pointers set to nothing.

I have written quickly here and off the top of my head. But you will
get the idea. Sometimes if Form_Open initial code makes a form
invisible then the .Visible Property will have to be set to true. I
think this is good standard practice. Of course, if you want to use a
normally visible form as invisible you have only to
From_Form1.Visi ble = False
provided it's initial code doesn't set it back to visible.

And as previously noted the form must have HasModule set to true or it
must have a module (the only way for Access 97 I believe).

[Wayne Gillespie]

On Sat, 12 Aug 2006 14:21:25 -0500, "David W. Fenton"
<XX*******@dfen ton.com.invalid wrote:

>Wayne Gillespie <be*****@NOhotm ailSPAM.com.auw rote in
news:f7******* *************** **********@4ax. com:

>On Fri, 11 Aug 2006 22:09:48 GMT, Lyle Fairfield
<ly*********** @aim.comwrote:

>>>"David W. Fenton" <XX*******@dfen ton.com.invalid wrote in
news:Xn***** *************** **************@ 127.0.0.1:

But the drawback of that approach is that it's limited to forms
not opened modally.

I think this is not so, as I previously explained.

I pass values to and set properties in modal forms all the time
without any problems.

You pass values to modal forms opened with acDialog? As in this:

DoCmd.OpenForm "dlgMyDialo g", , , , , acDialog
Forms!dlgMyDial og.MyProperty = "Foo"

How exactly does that work? Code pauses at the DoCmd.OpenForm line
and so the things you set won't be set when the user gets control of
the dialog.

You did not mention opening the form acDialog. That is another kettle of fish.

Your statement above and in previous post in this thread is that - "it's limited
to forms not opened modally" is not correct.
Wayne Gillespie
Gosford NSW Australia

[David W. Fenton]

Wayne Gillespie <be*****@NOhotm ailSPAM.com.auw rote in
news:hl******** *************** *********@4ax.c om:

On Sat, 12 Aug 2006 14:21:25 -0500, "David W. Fenton"
<XX*******@dfe nton.com.invali dwrote:

>>Wayne Gillespie <be*****@NOhotm ailSPAM.com.auw rote in
news:f7****** *************** ***********@4ax .com:

>>On Fri, 11 Aug 2006 22:09:48 GMT, Lyle Fairfield
<ly********** *@aim.comwrote:

"David W. Fenton" <XX*******@dfen ton.com.invalid wrote in
news:Xn**** *************** *************** @127.0.0.1:

But the drawback of that approach is that it's limited to
forms not opened modally.

I think this is not so, as I previously explained.

I pass values to and set properties in modal forms all the time
without any problems.

You pass values to modal forms opened with acDialog? As in this:

DoCmd.OpenForm "dlgMyDialo g", , , , , acDialog
Forms!dlgMyDial og.MyProperty = "Foo"

How exactly does that work? Code pauses at the DoCmd.OpenForm line
and so the things you set won't be set when the user gets control
of the dialog.

You did not mention opening the form acDialog. That is another
kettle of fish.

How else do you open a form modally?

Your statement above and in previous post in this thread is that -
"it's limited to forms not opened modally" is not correct.

The modal flag does not open the form modally from code, i.e.,
causing the code to pause. Thus, I don't ever set the modal flag in
forms.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/