Hi,

I have (had) the following problem which i worked around but i would still
like to find an answer.

if myDate is e.g. : #02/04/1998# how do i extract the year ?

Year(myDate) is only for VBA.
myDate.Year doesnt exist.

Any suggestions ?

Thanx in advance !
-steve

Newbie wrote:
Not sure what you mean by 'only for VBA', since

?Year(Now)

seems to work fine in VB6's Immediate window.

The Year function works fine in VBA, VB5 and VB6 on my system. Try:

MsgBox Year(Now)

Which version of VB are you using?

Mike

Since when?

I found that VB6 does not prevent you from using Year as a variable, and
hence, some developers think it doesn't work.


Show quoteHide quote

I just found out that if you use "Year" as an item in Enum, it will not
work. It would give you a compile time error.

Example:

Private Enum enumDates
    Year
    Month
    Day
End Enum

This will override Year(), Month(), and Day() functions since they are part
of VBA library, which is part of VB6.

To avoid these problems, I always prefix Enum elements with "enm" or "enum".
Most likely I would write it like this:

Private Enum enumDates
    enmDateYear
    enmDateMonth
    enmDateDay
End Enum



news:pnXXe.44109$ct5.2692@fed1read04...
Show quoteHide quote

you can use year,month,day in an enum
if you use the full syntax for the vba functions
example:
Private Enum enumDates
    Year
    Month
    Day
End Enum

Private Sub Command1_Click()
    Print VBA.Year(Now), VBA.Month(Now), VBA.Day(Now)
    Print Year, Month, Day
End Sub

news:eMXXe.44114$ct5.9164@fed1read04...
Show quoteHide quote

news:pnXXe.44109$ct5.2692@fed1read04...

It doesn't prevent you from using any function name as a variable. One
regular around here posted some code a while back with a variable named
"str" which he said he used all the time as a throwaway name. We were
surprised that it didn't conflict with the Str() function, and he was
surprised to learn that the Str() function existed. Gotta love VB....

Show quote Hide quote My favorite "shoot oneself in the foot"...

I created a Class mimicking a data structure and one of the members was
"ID". So I created a quite logically named member variable - "mID".
I am embarrassed to report that there several hours of grief before I
recognized what the problem was. <g>

-ralph

Show quote Hide quote And the IDE never changed it to Mid?

Show quote Hide quote Never. Well, never so much that I noticed it.

I was so dense at the time, that when I got a peculiar error, I was always
able to "get around" it. I was using a class generator.

I can't remember the exact final situation, but I think it was while using
it as a parameter. Error would be something like wrong parameters, etc. I
kept chewing on the original call. <g>

I hit the floor laughing, when it finally dawned on me.

-ralph

Show quote Hide quote Jeff,

When I read this the other day, it rang a bell that I had just added mID to
one of my classes.
I just got a chance to investigate it, and I had to share:

When I searched for "mID", I found that all of my Mid() functions had been
"renamed" to mID.
Typing over them didn't help, either; they would just revert to from Mid()
back to mID().
Interestingly, there were no errors, and when I right-clicked mID, and
selected "Definition", it went to the Dim'd one.

In an attempt to fix it, I renamed my member variable (I used m_ID), but the
mID() held its caseness (made that up myself).
Even after saving, exiting, and restarting VB, it persisted!

To fix it, I Dim'd a variable with the correct case, saved it, deleted the
"Dim Mid..." line, and re-saved it.

Fun, fun,

DRBarkley

On Thu, 22 Sep 2005 07:46:06 -0500, "Ralph"
<nt_consultin***@yahoo.com> wrote:

<snip>

Nice One !

You outscoped Mid - how comical

I avoid that sort of problem by using UDTs

  Private Type TM
        ID As String
        OtherProp AS OLE_COLOR
  End Type

  Private m As TM

Show quote Hide quote I avoid it by using the underscore with my scope identifiers:

    m_ID vs. mID

Other than constants, it's my only use of underscores in variable names.
(But then constant isn't a variable, now is it? You know what I mean....)

Show quote Hide quote Not that I or anyone else around here have blind personal preferences. <g>

I avoided "warts" (m_xxx). I, who abuse Hungarian outragiously, just thought
they looked ugly. Even going so far as calling it toad-programming. However,
since having been bitten several times in the proverbial location, I have
learned to appreciate their usefulness. <g>

-ralph

On Fri, 23 Sep 2005 12:10:04 -0500, "Ralph"
<nt_consultin***@yahoo.com> wrote:

<snip>

Except for Objects (especially visual ones)  I really dislike
Hungarian notation

One can spend ages looking at the prefix wondering
    'What the heck does that lot mean ?'

- acbogJerry  ( a virtual beer to anyone who can suss that out )

<g>
Show quoteHide quoteI love Hungarian notation. I adopted it early using a home-grown version in
my pre-ANSI C days. It has a proven track record in assisting programmers to
write readable and maintainable code.

Like all standards it depends on one to actually use the 'standard' - I
suspect that you have either combined several conventions (MS, ADO,
Leszynski, Hungarian, ...) or it is malformed. (My guess - you meant to type
"gacboJerry".)

In any case a variable 'name' is always meaningless when removed from the
context in which it was used. Whether 'English' or 'Hungarian'.

-ralph
(8 lines, poor)

On Sat, 24 Sep 2005 09:36:56 -0500, "Ralph"
<nt_consultin***@yahoo.com> wrote:
<snip>

I first really ran into it when one part of our shop was migration to
C in order to use OS/2

The problem was that their system used (and needed) a fair variety of
complicated types, the Hungarian just became illegible.

Not necessarily, with a little common sense one can establish
meaningful names that are still 'meaningful' out of 'context'

For example:
     InRoutineFlag   is a Boolian preventing recursion

     By convention Flag is always Boolean
     (even before Boolean existed)

Another problem with using Hungarian for simple variables is that one
may wish to change a data type from say, Integer to Long, so one has
to go through changing : iCount to lCount

If one is sensible then one only gives 'names' to things with a life
longer than a dragon fly :
        S is a much easier thing to recognize than sTemp

By my convention 'S' /is/ 'temporary' so sTemp is repetitious

Similarly  P  is a dragonfly pointer but pStart is significant

IMO a smattering of Hungarian is useful, but excessive use of it makes
one forget 'Plain English'

To a degree, yes.  "CustomerName" is probably a string while
'TotalAmountDue' is probably currency; at the very least you know it's
probably numeric.

by your convention; by the convention many use possibly.  by the conventions
that I use 'flag' would indicate a numeric variable that can take on any of
several states

True enough although I can't remember a case where I've needed to do that.
It's probably come up but with a global search and replace it's not like it
takes all that long to do.  The tradeoff in being able to see the data type
readily while working with the code makes the risk more than worth it as far
as I'm concerned.

I *might* use 's' for a string in an isolated routine of a half-dozen lines
or so where the intent is obvious and the declaration is right there.
Anything longer and 'sTemp' I find much more easily read.

p for pointer?  don't have much use for that in VB! <g>

I think we agree on that in the general sense but I'll bet our definitions
of 'excessive' don't line up too well! <g>

Use (and abuse) of naming conventions is definitely mostly personal
experience and preference.  One person's elegant system is another's awkward
jumble.  I've long held that it's really more important to have some sort of
system and use it consistently than what the details of that system are.

On Sun, 25 Sep 2005 05:56:49 -0700, "Bob Butler"
<tiredofit@nospam.com> wrote:

Agreed - generally I work 'Sum' into the name to indicate Currency

To me that would probably be 'Value'
- possibly an Enum

Normally I get bitten on String stuff there
- the old assumptions from very old Strings

Actually I'm keen on $, & an %  especially when calling APIs
- the Suffix /cannot/ lie

No, if is more than a dragonfly it would get a name of some sort

Oddly I do occasionally find uses for it
- normally APIs
- or when sorting an Integer/Long Array that indexes another Array or
offsets

Partly I find excessive 'Hungarian' very ugly
- but agreed about the 'definition'

I'll certainly agree that an /inconsistent/ set of conventions is a
complete nightmare

However, I do like code to read like 'plain English'
- generally one gets something working fine, but to understand it one
has to squint at the code
- a bit of extra time 'combing' the code often improves the algorithm,
and makes maintenance a lot easier

Partly the acid test is looking at some old code and asking :-
   'What idiot wrote that ?'

The answer is generally very embarrassing  <g>

All I can say about that is "blech!"
<g>

On Fri, 23 Sep 2005 10:09:31 -0400, "Jeff Johnson [MVP: VB]"
<i.get@enough.spam> wrote:

<snip>

Yes, I started off using that convention
- but it looked ugly
- and I found the side effects of using a UDT rather useful

Ditto - and I agree about Constants not really being Variables
.... although in some languages you can 'Writeable Constants'
- a concept that makes my stomach heave

Show quote Hide quote As Larry pointed out, Year(myDate) does return the year in VB6.  Are you
using VB.Net?

Jim Edgar

VB6 : Attach Event Handlers to Dynamically Generated Controls
Newbie: FOR loop on dates
Declaring a Constant
List all jpg files from folder (loop problem)
Random first random number
Question on printing with Snapshot from VB 6
Do The Runtime DLLs Come With Win2000?
delete
XMLdoc for VB
VB6 IDE VBE Object reference