"With . . . End With" question

  • Thread starter Thread starter Gary Schuldt
  • Start date Start date
G

Gary Schuldt

I'm having a little trouble finding documentation on this command. From the
examples I've seen, it looks like it sets a scope for variables whose names
begin with a qualifier like "!" or ".", as in:

With rs
.Edit
!SortKey = strSortKey
!Line1 = varLine1
!Line2 = varLine2
!Line3 = varLine3
.Update
End With


I think the only examples I've seen, however, are lines that BEGIN with a
qualifier mark . Does it work for references within a line, such as?

With rs
strGenus = !Genus
strSpecies = Nz (!Species)
End With

Gary

(BTW, when I googled with "end with", the first useful explanation of it
came in German!
http://www.galileocomputing.de/openbook/vb_net/msvb020003.htm#Rxxmsvb0200032
56WithEndWith
 
Gary Schuldt said:
I'm having a little trouble finding documentation on this command.
From the examples I've seen, it looks like it sets a scope for
variables whose names begin with a qualifier like "!" or ".", as in:

With rs
.Edit
!SortKey = strSortKey
!Line1 = varLine1
!Line2 = varLine2
!Line3 = varLine3
.Update
End With


I think the only examples I've seen, however, are lines that BEGIN
with a qualifier mark . Does it work for references within a line,
such as?

With rs
strGenus = !Genus
strSpecies = Nz (!Species)
End With

Gary

(BTW, when I googled with "end with", the first useful explanation of
it came in German!
http://www.galileocomputing.de/openbook/vb_net/msvb020003.htm#Rxxmsvb0200032
56WithEndWith

I doin't like to be snippy, Gary, but did you look in the VB help file
under "With Statement"? The discussion there seems pretty complete to
me. Of course, you may have called up help from the Access application
environment, not realizing that <sigh> you get a different set of help
topics when you open help from the VB Editor environnment.

One thing the help topic doesn't make completely clear is that yes, it
works for references within a line, not just at the beginning.
 
I doin't like to be snippy . . .

I'm sure you don't, Dirk . . . if it ever became public, the consequent
demerits might jeopardize your MVP license renewal . . . LOL
. . . but did you look in the VB help file under "With Statement"?

Of course not! (And how do I know? Just now when I opened it, it popped up
a "Preparing for first use . . . " message box said:
Of course, you may have called up help from the Access application
environment . . .

How ever in the world did you guess THAT??! No wonder, when I typed "with",
the only hit I got was "width" . . .

BUT . . . then why isn't there anything in VB Help about Nz()?? I still
have to google to find out anything about that function . . . and someone
out there wrote that it isn't even standard VBA at all, just an MS Access
extension.
One thing the help topic doesn't make completely clear is that yes, it
works for references within a line, not just at the beginning.

Yeah, it sure doesn't. Help uses imprecise terminology like "executing" or
"performing statements on an object . . . " Like I said, whenever you
finish your book . . . It would have been much more enlightening for it to
read something like "for any reference to the specified object within the
block".

Anyway, thanks for clearing it up. This plant labeling code will be SO GOOD
when it finally gets written: Not only will it be the most economical,
elegant, efficient and maintainable code the MVP community can produce . . .
but it might also work!!

Gary
 
Gary Schuldt said:
I'm sure you don't, Dirk . . . if it ever became public, the
consequent demerits might jeopardize your MVP license renewal . . .
LOL

Oh, we're allowed to be snippy. For some it's a lifestyle.
BUT . . . then why isn't there anything in VB Help about Nz()?? I
still have to google to find out anything about that function . . .
and someone out there wrote that it isn't even standard VBA at all,
just an MS Access extension.

Someone's right, but you shouldn't have to google for it. It's in the
Access application help file, along with a whole lot of other useful
Access-specific programming info, under "Programming in Visual
Basic/Microsoft Access Visual Basic Reference/Methods/Nz Function".
Unfortunately, the help system in A2K/A2K2 is broken in a big way, and
it doesn't come up in a search from the application window. Oddly, it
does come up in a search from the VB Editor window, even though it isn't
in that help file's table of contents at all.

Here's a tip for working with the broken help system: the quickest way
to find most programming-related help topics is to type the keyword in a
code window or in the Immediate Window, then press F1 while the cursor
is on or adjacent to the keyword you typed.
 
Wow! It's like the clouds parting to reveal a 14,000' peak! All the things
that you folks know already but I couldn't find are now revealed!

In Access 2K Help, I found it by going:

Programming Information
Microsoft Access Visual Basic Reference
Functions . . .

Also great tip on using F1 in the coding window . . .

Thanks again, Dirk . . .

Gary
 
a "Preparing for first use . . . " message box, that's how <scowl>.)



:-) That's broken also...... I get that message every day !


(david)
 
David said:
:-) That's broken also...... I get that message every day !
Maybe it's because your running with low memory . . .

urrk . . .. !

You folks all talk about Help being "broken": My question is, "Who broke
it??"

Gary
 
Gary Schuldt said:
Maybe it's because your running with low memory . . .

urrk . . .. !

You folks all talk about Help being "broken": My question is, "Who
broke it??"

It wasn't me, I was nowhere near the place!

When MS changed the help system to use HTML Help -- for whatever
reason -- they separated the help files and their indexes, and somehow
manged to screw things up so badly that it became practically impossible
to find what you're looking for in the help file unless you already know
where it is. This was also aggravated by the change to the VBA
programming environment, separating it and its help topics completely
from the application window. The help content is all still there, as
far as I can see, but the indexing and search facilities are practically
worthless.
 
Help files are compiled HTML. They used to be compiled RTF.
There is no obvious reason why changing the viewer or the
source format should break help

I don't know HTML help, but I'll bet it doesn't use the tagging methods of
Help Workshop. (Eg. to add a word to the index, you have to underline
alternate characters in pink and blue; change its font to 13.5 Arial; apply
strikeout formatting to the next 8 words (except the 6th); then turn to face
Mecca - except on alternate Thursdays.)

That is, the source files would have needed significant re-engineering, I
imagine. Plenty of chances to stuff it up there.

TC

so I lean towards the
opinion that 'breaking' is an implementation fault rather
than a fundamental design strategy :)

(david)

(snip)
 
Help files are compiled HTML. They used to be compiled RTF.
There is no obvious reason why changing the viewer or the
source format should break help, so I lean towards the
opinion that 'breaking' is an implementation fault rather
than a fundamental design strategy :)

(david)
 
But you are surely not suggesting that a simple translation of rtf tags to
the equivalent html tags would be all that was required?

TC
 
In RTF, you added a tag to a word to indicate that
the word was a hyperlink. The help compiler ran through
the RTF and found all the tagged items, and created the
index that WinHelp used to jump to the Page. The Find
index could be created separately, at runtime, by reading
the saved text.

Tags were things like this:
{\uldb}
Because this system predated tools like FrontPage,
it used RTF tags as generated by Word 2, rather than
HTML tags. (uldb actually means UnderLine DouBle, and
the tagged section has a double underline in Word)

The system worked well with Word 2. (That is, Word 2,
not Word For Windows, not MS Office 95 etc etc). Later
versions of Word got progressively more complex, and
generated RTF files that were larger and larger, while
not having any more real content. The help compiler
was not rewritten to tolerate RTF generated by other
programs, and with Word 6 the system was already a bit
flaky. When writing help file RTF in a simple text
editor, you needed to be careful about the placement
of line breaks.

(david)
 
But you are surely not suggesting that a simple translation
of rtf tags to
the equivalent html tags would be all that was required?

um... yes, for the source file: In fact, looking at the new
help files, it looks like they just loaded the old (RTF) help
files into Word, and saved them as HTML - And if all they
wanted to changed was the source format, they could have used
the Word filter to convert from HTML to RTF, and then used
the old Help Compiler.

At the other end, it looks the same: the help system displays
Text with Hyperlinks and an Index. It does NOT look like a
fundamentally different metaphor for help display.

(david)
 
david epsom dot com dot au said:
um... yes, for the source file: In fact, looking at the new
help files, it looks like they just loaded the old (RTF) help
files into Word, and saved them as HTML - And if all they
wanted to changed was the source format, they could have used
the Word filter to convert from HTML to RTF, and then used
the old Help Compiler.

At the other end, it looks the same: the help system displays
Text with Hyperlinks and an Index. It does NOT look like a
fundamentally different metaphor for help display.

Ok, thanks for that info. I was skeptical that they would have done it that
way. But apparently so!

TC
 
Ok, thanks for that info. I was sceptical that they would have
done it that way. But apparently so!

:-) I meant they /could/ have been done it that way - and that
given the simplicity of the task, it looks like an implementation
problem rather than a design problem. Actually, moving to HTML/
Internet Explorer means that we have a richer Help environment,
and means that they don't have to support two hypertext mark-up
languages, and two hypertext mark-up rendering and display systems.

I would say that there are 4 problems with A2K/A2K2 help:

1) The VBA help does not support floating windows. Instead the
help and project windows etc are implemented kind of like menu's.
2) The Help Wizard is poor and inappropriate.
3) The Index is too small.
4) There is no 'FIND' index.

I don't see any of these problems as being inherent in the move
from WinHelp to HTML help, although (4) certainly may be. Rather,
I see the problem as being the almost traditional Access problem:
Access is at the rear end of Office development....

just my 2c.

(david)
 
Back
Top