Replies

See if the following helps:
WINUP-Problems When Viewing or Downloading From Windows Update

You might need to open a module or code, then select Tools-References.

Check the box for Microsoft Word Object Library (it will have a version #, depending on which you are using)

Peter,
I think next I would go ahead and try setting up your email again from Tools-Accounts in OE, putting in the real email server names, instead of the Norton Supplied ones.
This will tell you whether you have an email issue, or a Norton one.

Remember, virus scanning for email will be disabled if you do this.

See if the following document helps:

Error: “0x800ccc0e, Socket Error 10061” when using Outlook Express

Charlotte,
You are of course correct, I had completely missed being able to return an array inside a variant.

ByRef can be very useful, in some situations. I think I suffer some semantics issues, since I tend to think of it more as modifying existing values, as opposed to truly returning a value (with some exceptions); and since it lends itself to abuse, I tend not to use it much, except in those situations where it is clearly warranted.

Thanks for pointing out the error in my previous message, I certainly don’t want to mislead anyone with my advice.

Chris,
I think the issues of SUB vs FUNCTION, and the building of procedures in general are worthy of further discussion, and can help us all become better programmers. (Note: I will try to use “Procedure” to refer to either a sub or function, but the terms “sub” or “function” when I mean one of them explicitly).

You have promoted two concepts in various threads, that I wish to respond to.

A Sub should never be used.
First, and I think you have pointed this out, a SUB is necessary when programming in the VBA environment, if you wish to expose your macros to the user.

My personal opinion is to follow the convention that a Function returns a value, whereas a Sub does not. Most standard coding that you will read uses this convention. When you start to program subs as functions, returning essentially useless values from them, you make the calling procedure harder to read; you expose your code to more programming errors, and you lessen the portability of the sub that is now a function procedure. (for instance, you run the risk of moving it’s error checking into the calling procedure, as opposed to raising an error in the sub which is usually better). You stated that you challenge people to write a sub that cannot return a useful value, but I would say that in many instances, a sub (written as a function) can only return a value of whether it succeeded or failed, and in most of those cases, efficient error code in the sub is more appropriate than in the calling procedure. The exception sometimes being when the calling procedure must fail if the sub fails, but again, raising an error may be more approprite for handling this, since at best, a procedure failing because a sub function failed will never tell you why the sub function failed, only that it did, whereas a raised error can tell you that information.

A Function should only take in two values, and then return one value.
I strongly disagree with this statement, and feel it limits and unnecessarily complicates code. My definition of a function (or a sub for that matter), is it should perform one specific task, and it should perform it well. To arbitrarily limit these values to only two values in does not in my opinion constitute good coding practice, rather it limits the ability to code good, and can hinder instead of enhance the portability of your code. Example: (pseudo – coded)

Function CompTrapezoidArea(aSide, bSide, Height)
     CompTrapezoidArea = 1/2(aSide + bSide) * Height
End Function

Breaking the above into two functions would serve no purpose other than to unnecessarily involve an intermediate step.

I’ve enjoyed your code samples, and look forward to seeing more of them. I do think it is helpful for all to hear differing viewpoints on various coding styles and develop styles that work well for themselves, and the people who use there code.

See This thread

I think it is worth pointing out that your function does NOT return more than one value; rather, it returns one value, but also sets some variables which can then be used by the calling procedure. This type of workaround opens up a whole host of potential problems, not the least of which is if error checking needs to be used. I must agree that you are much better off returning only one value from a function, and if two values are needed, many headaches can be avoided by using separate functions.

It is also worth mention that VBA does not have any way to return more than one value directly, although in VB 6 (not VBA), you can return an array which can often yield desired results. I have also seen other workarounds such as concatenating strings and breaking them apart; and other methods to get around this. But, as a very good general rule, you should look hard at your code, and determine if it can be broken down into separate procedures.
[indent]

---

I hold that it is a generally good programming practice (programming, not just programming-in-VBA) to write functions rather than subroutines, and to write functions that compose two incoming arguments into one outgoing result.

This is not always achievable, but when it is, it makes for more readable code, I maintain.

---

[/indent]
I also have some thoughts on this issue, but think they will be better served on their own thread, as opposed to bogging this one down.

Tools-Customize, Command Tab, click Keyboard Button, then select macro and key assignment.

There are several ways, a lot depends on your setup.

Try this first:
In Control Panel, under “Users and Passwords:
1. On the Users tab, uncheck “Users must enter a username and password”

2. On the Advanced tab, uncheck “Require users to press”

3. Click OK or Apply, and a window will popup where you enter the username & password of the account you want to automatically log on with.

You can also see: for other suggestions, as well as download TweakUI 1.33 (supports Win2k) and use that. Again, a lot depends on your specific user and/or security needs.

I’ve attached the code as a text file, to be sure it translated correctly to your machine.

Also, using a registry search is a sometimes “iffy” thing. Programs can get away with not having entries where they are supposed to.

It really depends on what program, and how it is entered in the registry. Some other keys that might have value (but should be tested thoroughly):

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionUninstall
(add the name of the program from the Add/Remove Programs box)
in the function this would be:

strAppExists = System.PrivateProfileString(“”, “HKEY_LOCAL_MACHINE _
& SoftwareMicrosoftWindowsCurrentVersionUninstall” & strAppName, “Display Name”)
‘(where strAppName is the name of the program from the Add/Remove Programs box)

You can also try checking the program associated with the file extension.
To get the right key, look at:

HKEY_CLASSES_ROOT.dwg
on the right, it should list the Default Value as something like dwgfile

then further down the reg key, look for:

HKEY_CLASSES_ROOTdwgfileshellopencommand
(replacing dwgfile with the actual name, if different)

This will tell you what program is associated to opening this file type.
This may be some trial and error, to find where your program reference actually is.

BAM,

Thanks, I never knew that was there, it seems quite helpful. One thing to note though is it runs up against one of the limitations I found when writing my macro, it misses hidden text, text boxes, and header / footer text. I guess it really depends on where you need the font info from.

Don,
Very nice piece of code. The only drawback I see is that a lot of users are disabling/renaming windows script, due to the proliferation of viruses that use it (Not taking a position either way on that issue ). But, if present, that code works well.

With that in mind (and borrowing heavily from your concept), how about the following:

Function strAppExists(ByVal strAppName As String)

    strAppExists = System.PrivateProfileString("", "HKEY_LOCAL_MACHINESoftware" _
    & "MicrosoftWindowsCurrentVersionApp Paths" & strAppName, "Path")

End Function

Will return either the app path, or “” if not found. It could then be called by something similar to:

Function CheckApp()
Dim strCheckApp, strAppName
strAppName = "excel.exe"
strCheckApp = strAppExists(strAppName)

If strCheckApp = "" Then
    MsgBox UCase(strAppName) & " not found"
Else
    MsgBox UCase(strAppName) & " found installed at " & strCheckApp
End If

End Function

Thanks Gary, I did.

Sub ListFontsUsedinDoc()
'James Brooks  February 2001
'Credit: Gary Frieder for some plagiarized code snippets
'Purpose:   List all fonts in use in a document

Dim strFonts As String

Set objView = ActiveWindow.View
bHidden = objView.ShowHiddenText 'show hidden text if currently hidden
objView.ShowHiddenText = True

 For Each aStory In ActiveDocument.StoryRanges
    For Each aFont In FontNames
       With aStory.Find
                .ClearFormatting
                .Font.Name = aFont
                .Wrap = wdFindContinue
                .Forward = True
                .Format = True
                .MatchCase = False
                .MatchWholeWord = False
                .MatchWildcards = False
                .MatchSoundsLike = False
                .MatchAllWordForms = False
                If .Execute = True Then
                        'This fills a string with the font list that
                        'is then displayed in the message box, but
                        'you could do whatever you need to with the
                        'font names here
                        If InStr(strFonts, aFont) = 0 Then
                        strFonts = strFonts & vbCrLf & aFont
                        End If
                        
                End If
        End With
    Next aFont
Next aStory

'restore show hidden setting:
objView.ShowHiddenText = bHidden

MsgBox "Fonts in Document:" & vbCrLf & strFonts

End Sub

Here is my crack at it. Kind of a different approach, not sure which is better, or if mine is flawed; I welcome any comments.

Sub ListFontsUsedinDoc()
Dim strFonts As String

Set objView = ActiveWindow.View
bHidden = objView.ShowHiddenText 'show hidden text if currently hidden
objView.ShowHiddenText = True

For Each aStory In ActiveDocument.StoryRanges
    For Each afont In FontNames
        With aStory.Find
                .ClearFormatting
                .Font.Name = afont
                .Wrap = wdFindContinue
                .Forward = True
                .Format = True
                .MatchCase = False
                .MatchWholeWord = False
                .MatchWildcards = False
                .MatchSoundsLike = False
                .MatchAllWordForms = False
                If .Execute = True Then
                        'This fills a string with the font list that
                        'is then displayed in the message box, but
                        'you could do whatever you need to with the
                        'font names here
                        strFonts = strFonts & vbCrLf & afont
                End If
        End With
    Next afont
Next aStory

'restore show hidden setting:
objView.ShowHiddenText = bHidden

MsgBox "Fonts in Document:" & vbCrLf & strFonts
End Sub

Gary,
I just pretty blatantly plagiarized your hidden text code, hope you do not mind.