how set default property in VB 6
Joe
Option Explicit
Private m_ShapeMaster As String
Private m_ShapeText As String
Public Property Let Shape(s As String)
m_ShapeMaster = s
End Property
Public Property Get Shape() As String
Set Shape = m_ShapeMaster
End Property
Public Property Let Text(t As String)
m_ShapeText = t
End Property
Public Property Get Text() As String
Text = m_ShapeText
End Property
Public Sub Clear()
m_ShapeMaster = vbNullString
m_ShapeText = vbNullString
End Sub
TIA,
--
Joe
VBA Automation/VB/C++/Web and DB development
Ken Halter
> I am using VB 6.0 and need to know how to set a default property. IN the class module code below, what determines which property is the default property?
Nothing shown. It's a setting you need to set in the Procedure
Attributes dialog. Tools/Procedure Attributes/Advanced Button/Procedure
ID/Default
After doing that, forget it <g> It's not a good idea to rely on any
objects 'Default' property imo. Not supported at all in the "next"
version of VB anyway so...
--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..
Peter Young
> Joe wrote:
> > I am using VB 6.0 and need to know how to set a default property. IN the class module code below, what determines
which property is the default property?
>
> Nothing shown. It's a setting you need to set in the Procedure
> Attributes dialog. Tools/Procedure Attributes/Advanced Button/Procedure
> ID/Default
Note too that you can set this/see this using a plain text editor. After setting the default, your property will have
another line that you don't see in the IDE.
e.g.
Public Property Let Text(t As String)
m_ShapeText = t
End Property
Public Property Get Text() As String
Attribute Text.VB_UserMemId = 0
Bob O`Bob
>
> Not supported at all in the "next"
> version of VB anyway so...
I think everyone should stop saying things like that, since
currently no one actually knows whether there will be another VB.
No point in misleading folks more than MS already has.
Bob
Joe
--
Joe
VBA Automation/VB/C++/Web and DB development
Joe
--
Joe
VBA Automation/VB/C++/Web and DB development
Jeff Johnson [MVP: VB]
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
news:%23p7MXNg...@tk2msftngp13.phx.gbl...
> After doing that, forget it <g> It's not a good idea to rely on any
> objects 'Default' property imo. Not supported at all in the "next"
> version of VB anyway so...
I have weaned myself from using default properties in most instances,
however when it comes to collections, I absolutely expect them. Who actually
writes
x = rsTemp.Fields("RecID").Value
or
x = MyCollection.Item("MyKey")
Everyone expects to be able to do
x = rsTemp("RecID").Value
and
x = MyCollection("MyKey")
Even .NET supports this!
Ken Halter
> I have weaned myself from using default properties in most instances,
> however when it comes to collections, I absolutely expect them. Who actually
> writes
Well... I don't do much DB work but when I do, the first line below is
how it looks.
> x = rsTemp.Fields("RecID").Value
>
> or
It's true that I don't access collection items like the line below so I
guess there's at least one default property I rely on.
> x = MyCollection.Item("MyKey")
>
> Everyone expects to be able to do
>
> x = rsTemp("RecID").Value
>
> and
>
> x = MyCollection("MyKey")
>
> Even .NET supports this!
Nothing like being consistant eh? <g> Another one that bugs me is the
Text vs Caption issue. Most (if not all) MS controls use Text where it
used to be Caption... too bad no body told the 3rd party developers
'cause they're still using Caption in almost every case I've seen.
Bob Butler
news:Oo%23FIpgX...@TK2MSFTNGP11.phx.gbl
> news:%23p7MXNg...@tk2msftngp13.phx.gbl...
>
>> After doing that, forget it <g> It's not a good idea to rely on any
>> objects 'Default' property imo. Not supported at all in the "next"
>> version of VB anyway so...
>
> I have weaned myself from using default properties in most instances,
> however when it comes to collections, I absolutely expect them. Who
> actually writes
>
> x = rsTemp.Fields("RecID").Value
*always*
what I draw the line is
x = rsTemp.Fields.Item("RecID").Value
> or
>
> x = MyCollection.Item("MyKey")
quite often although I admit to being inconsistent with that syntax
> Everyone expects to be able to do
>
> x = rsTemp("RecID").Value
>
> and
>
> x = MyCollection("MyKey")
expectations (aka assumptions) can get you into trouble; best to have none!
> Even .NET supports this!
speaking of havign no expectations.... <g>
--
Reply to the group so all can participate
VB.Net... just say "No"
Bob Butler
<cut>
> Nothing like being consistant eh? <g> Another one that bugs me is the
> Text vs Caption issue. Most (if not all) MS controls use Text where it
> used to be Caption... too bad no body told the 3rd party developers
> 'cause they're still using Caption in almost every case I've seen.
Yeah, that one really grates. It was always a useful distinction: .Caption
properties are "output only" while .Text properties are "input/output" (at
least normally). Under .Net you don't know from the name whether to expect
to be able to allow user editing or not.
MikeD
"Jeff Johnson [MVP: VB]" <i....@enough.spam> wrote in message
>
> "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message
> news:%23p7MXNg...@tk2msftngp13.phx.gbl...
>
> > After doing that, forget it <g> It's not a good idea to rely on any
> > objects 'Default' property imo. Not supported at all in the "next"
> > version of VB anyway so...
>
> I have weaned myself from using default properties in most instances,
> however when it comes to collections, I absolutely expect them. Who
actually
> writes
>
> x = rsTemp.Fields("RecID").Value
That's the syntax I always use. You're still, however, relying on Item being
the default for the Fields collection. To completely eliminate use of any
defaults, you'd need to write it as
x = rsTemp.Fields.Item("RecID").Value
>
> or
>
> x = MyCollection.Item("MyKey")
You don't see that a whole lot. The Item property/method (I've seen it
written, and even documented by MS, as both) of a collection is the ONLY
default I ever rely on.
>
> Everyone expects to be able to do
>
> x = rsTemp("RecID").Value
You're relying on TWO defaults there. The Fields property of the Recordset
object and the Item property of the Fields collection. If you're gonna do
that, you might as well write
x = rsTemp!RecID
(which is not much worse)
Mike
Ralph
"Bob Butler" <tire...@nospam.com> wrote in message
news:uJzqEIhX...@TK2MSFTNGP12.phx.gbl...
Sidenote.
When I brought that very thing up with some M$ friends (first release) - I
was told "that was a 'most' requested feature"!
I don't ever remember anyone asking for this. Do your remember it ever being
an issue? Who were these people?
-ralph
Bob O`Bob
> > > Nothing like being consistant eh? <g> Another one that bugs me is the
> > > Text vs Caption issue. Most (if not all) MS controls use Text where it
> When I brought that very thing up with some M$ friends (first release) - I
> was told "that was a 'most' requested feature"!
>
> I don't ever remember anyone asking for this. Do your remember it ever being
> an issue? Who were these people?
My guess: people who had never, and I mean *never* actually used VB.
I think Microsoft was soliciting thier opinions and asking questions
like "what would it take to get you to use VB?" ... totally oblivious
to the concept of *retaining* the millions of users it already had.
They seem to have thought that part was somehow guaranteed.
Bob