By the way, I ask only out of curiosity. There is no reason NOT to use two instructions (and once in a while a reason TO use two instructions), as there is virtually no performance hit. Just wondering why you would, without such a real reason to use two instructions.
You're right, it's just a bad habit that I have a hard time breakingpaul, why do you code separate Load/Show instructions?
I've been working on converting old code to use strings more effeciently, Load/Show just sort of fell off my radar screen
http://www.aivosto.com/vbtips/stringopt.html#whyslow
Paul
While old (not many people are still using VB6), that article is still very valid and should be required reading.
BTW, on review I can not think of any instance for needing a separate Load from Show instruction. The bottom line is a Show does a Load regardless.
It is kind of like that somewhat annoying combobox _Change event that fires when a userform starts up. If I understand it correctly, even though there is no apparent "change", technically speaking the combobox object is created, and THEN a null is given...thus a "change". Seems a bit wonky to me.
BTW, on review I can not think of any instance for needing a separate Load from Show instruction. The bottom line is a Show does a Load regardless.
I do think it's better to use the Load/Unload pair, because just .Hide doesn't seem to release memory
While the Load might not be required to make the VBA work, IMHO it's better style/preference/habit to always 'bracket' chunks of code, i.e. Load ... Unload
Test1 does not use Load/Unload and appears to consume memory, while Test2 gives the memory back when it's not needed anymore
[vba]
Option Explicit
Private Declare Sub GlobalMemoryStatus Lib "kernel32" (lpBuffer As MEMORYSTATUS)
Type MEMORYSTATUS
dwLength As Long
dwMemoryLoad As Long
dwTotalPhys As Long
dwAvailPhys As Long
dwTotalPageFile As Long
dwAvailPageFile As Long
dwTotalVirtual As Long
dwAvailVirtual As Long
End Type
Dim MemInfo As MEMORYSTATUS
Sub Test1()
Dim dwBefore As Long, dwAfter As Long
dwBefore = 0
dwAfter = 0
Call GlobalMemoryStatus(MemInfo)
dwBefore = MemInfo.dwAvailVirtual
UserForm1.Label1.Caption = "Welcome back"
UserForm1.Show
UserForm1.Hide
Call GlobalMemoryStatus(MemInfo)
dwAfter = MemInfo.dwAvailVirtual
MsgBox (dwAfter - dwBefore)
End Sub
Sub Test2()
Dim dwBefore As Long, dwAfter As Long
dwBefore = 0
dwAfter = 0
Call GlobalMemoryStatus(MemInfo)
dwBefore = MemInfo.dwAvailVirtual
Load UserForm1
UserForm1.Label1.Caption = "Welcome back"
UserForm1.Show
UserForm1.Hide
Unload UserForm1
Call GlobalMemoryStatus(MemInfo)
dwAfter = MemInfo.dwAvailVirtual
MsgBox (dwAfter - dwBefore)
End Sub
[/vba]
1. I thinkI'm doing the MemStatus correctly
2. It might not make any real difference
3. It might make a difference
Paul
Ah, but that is when you use .Hide. It is VERY rare that I ever use .Hide. I can not even think of the last time, as I fail to see how it is useful really. You MUST use .Show to unHide...which fires Load again. So what is gained?
"Test1 does not use Load/Unload and appears to consume memory, while Test2 gives the memory back when it's not needed anymore"
HUH??????
Well yes...but...HUH? Consume memory? Test1 still has memory allocated because it is still Loaded. Test2 releases it with Unload. They are not equivalent tests.
To see a (IMO) more significant value, get dwAfter after the .Hide (before the Unload.[vba] UserForm1.Show
UserForm1.Hide
Call GlobalMemoryStatus(MemInfo)
dwAfter = MemInfo.dwAvailVirtual
Unload UserForm1
[/vba]
A big goose egg. Bupkus. Nada. There is NO memory advantage to using .Hide. Which of course makes sense, as memory is still allocated.
.Hide does not just "seem" to not release memory...it does not release memory.
I do think it's better to use the Load/Unload pair, because just .Hide doesn't seem to release memory
While the Load might not be required to make the VBA work, IMHO it's better style/preference/habit to always 'bracket' chunks of code, i.e. Load ... Unload
Load IS required to make VBA work. Show fires .Load....always.
I am not sure what you mean by bracket.
A Show userform (which ALWAYS fires .Load) must always have an Unload.
There is a small reason for using .Hide, in that focus returns to the application. Whenever that comes into play (rare) I have found that a rethink is helpful. Perhaps making the userfom nonModal.
However, this becomes a design and useability issue (rather than a memory one), and almost invariably a rethink of the PURPOSE of the userform.
BTW: do you know of a way to identify ONLY the GUI resources involved with a userform. Remember the resources you are testing with your code are system resources, not specifically GUI resources.
big goose egg. Bupkus. Nada. There is NO memory advantage to using .Hide. Which of course makes sense, as memory is still allocated.True, no argument, I was only going by what Bill Gates says:
Unload Statement
Removes an object from memory.
Syntax
Unload object
The required object placeholder represents an object expression that evaluates to an object in the Applies To list.
Remarks
When an object is unloaded, it's removed from memory and all memory associated with the object is reclaimed. Until it is placed in memory again using the Load statement, a user can't interact with an object, and the object can't be manipulated programmatically.
BTW: do you know of a way to identify ONLY the GUI resources involved with a userform. Remember the resources you are testing with your code are system resources, not specifically GUI resources
Really wish I did. I'd really like to find out some what to see just how much the application is using
So if I'm reading you and Chairman Bill right, I could just use .Show and Unload if I wanted to, correct????
Paul
By the way is there any chance to count the highlighted words? Only Highlighted words?
Paul: : "So if I'm reading you and Chairman Bill right, I could just use .Show and Unload if I wanted to, correct????"
Yes, precisely. Show loads into memory. Unload unloads from memory. 99.999999% of the time there is no real need for using an explicit Load instruction, as .Show ALWAYS has an implicit Load instruction.
deedii, a running count? A total count?
Just count the total highlighted word but only in the "Article Page". I want to compute the percentage of the total duplicated words. So I will just count all highlighted red words. The formula Im thinking is
number of highlighted words from "Article Page" divided by the total words in "Source Page" times 100.
I presume that it will get the percentage of the duplicated words from the source.
You count highlighted words by...counting highlighted words.[vba]Sub CountHighlight()
Dim r As Range
Dim W As Range
Dim i As Long
Set r = ActiveDocument.Range
For Each W In r.Words
If W.HighlightColorIndex = wdRed Then
i = i + 1
End If
Next
MsgBox i & " words are highlighted."
End Sub[/vba]
You could also do a count by adding a counter to your Sub DoHighLight procedure. If so, because the procedure is closed each time, you will need to make the counter variable a PUBLIC variable in a standard module.
fumei thanks for that it works, and oh another thing can it also count the total of words in a page and divide it with the highlighted words times 100? I have a work around to ask the user the number of highlighted words to compute the percentage but i think it will be a hassle to do that, is there in any case to include the page word count(not the all page only SOURCE page) in [VBA]Sub CountHighlight()
[/VBA] to automatically compute the percentage?
Thanks much
"total of words in a page" This difficult because of the fluid nature of pages.
As for percentages, just do the math.
As for automatically, as I stated, do the count in your DoHighlight procedure.
Sorry to hijack deedii's thread, but I wanted to weigh in on show/load part of the discussion. Show loads into memory if you haven't yet loaded into memory, obviously. But my preferred standard is not to dimension something with the New keyword... so that, for me, my forms are loaded prior to the Show command.
[vba]
sub FormDemo
'This sets aside the memory space
Dim myForm as frmMyForm
'this loads it
Set myForm = New frmMyForm
'This shows it
myForm.Show
'this unloads it
Unload myForm
'this clears the memory space
Set myForm = Nothing
End Sub
[/vba]
I know that garbage collection isn't always effective in VBA, but apart from using New on the same line as the Dim statement, I actually like to have a separate action between loading my form into memory and displaying it to the user... it allows me to perform other actions I may or may not want to do before getting user interaction (apart from stuff within Initialize/Activate events for the userform itself).
But that is because I prefer to structure my code in such a way that the only code within a user form is related to the userform itself and the GUI for the user-- not any actions which will be performed after the form is dismissed.
Thoughts? Is this a stupid way of doing it?
EDIT: Fumei, it's good to see you back here
Oh, and I use .Hide all the time-- from within my form when the user hits "OK" ... and then my calling routine does the "work" of whatever my user has told my form to do.
OK, I will weigh in.
The radical difference is you are declaring a userform object. In none of the code posted so far has this been the case.
But my preferred standard is not to dimension something with the New keyword... so that, for me, my forms are loaded prior to the Show command.
Nor has the New keyword been used.
Oh, and I use .Hide all the time-- from within my form when the user hits "OK" ... and then my calling routine does the "work" of whatever my user has told my form to do.
But...why.
Well, you learn something new every day. I didn't realize that even with Option Explicit, you can avoid declaring your userforms as objects when you want to use them. I am in the habit of declaring userforms, so I didn't realize this loophole to the Option Explicit concept existed.
So even Paul's Sub "Test1" in my normal subroutine would include the following lines (at the appropriate location)
Dim f As UserForm1
Set f = New UserForm1
As well as garbage collection later to...
Unload f
Set f = Nothing
I *think* this is validating what I typically do, since Paul's code in Test1 is actually loading the form twice in some cases (UserForm1.Hide will also load the form, if it doesn't exist in memory -- i.e., someone has hit the Red X, or the ESC key if a command button has the CANCEL property set to true, and that command button has Unload Me in the _Click event, etc).
The reason I use Hide is because I typically do not allow a form to unload itself (since I always separate out my "information gathering" phase with my "do stuff" phase). So I require the form to remain loaded in my calling routine until I am done with it, in order to utilize the information I've collected. I realize this is more a preference rather than a requirement, but is the way I typically structure my code.
In practical application, this basically means that the code in my userforms is strictly restricted to modifying the form based on user interaction, and the code which performs actions on a document exists in the subroutine which called the form. There are exceptions to every rule, of course, but this is my general practice.
The reason behind it is, in really complicated forms which have to do extensive processing during initialization, I don't want to accidentally have those events happen more than once for a single routine (if the Userform falls out of scope, but code then later directly refers to it-- now I get a reloaded form, but I can't know whether the information from this reloaded form is accurate or not).
Of course, if all "action code" is within the form, then it is a self-encapsulated thing... so you don't have to worry about whether the form is loaded or not.
But, for me, it seems a bit more difficult to modularize (and thus, test) code which always requires me to run a userform, click on the option I'm testing, and then step through code to see if it works.
My practice is to set up routines with appropriate parameters, and be able to test those routines independently of any UI.
I realize this is a bit more theoretical in the various ways to structure code... but I'm always pleased to increase my understanding of items.
In looking at Paul's restructuring, he wouldn't run into an issue, because his main form calling routine "Compare" doesn't have any code after frmMain.Show.
However, even a frmMain.Hide after the frmMain.Show would reinitialize the form-- which would cause performance hits, depending on how much is going on in the Initialize event.
It's probably easier to demonstrate with a modification of the document code. Stand by
Perhaps my posts won't be such a hijack after all...
To the OP, Deedii --
Short answer: what you want isn't easy, and it might not be possible. I would investigate using Word's native comparison feature (even in Word 2003, it isn't bad).
Rich Text form controls are possible on VBA userforms, but you're trying to reinvent the wheel which has been programmed by Microsoft. You just want to compare two bits of text (source and article), to see what is similar.
The problem is, you're trying to add a feature (and thus, your brute force method) of getting an overall length of a string to compare. Why do you need to specify the "minimum length of matching parts"? In the document comparison world, this falls under the concept of "readability."
Are you trying to see if someone has plagiarized you?
I think we need a bigger picture of what you *really* want to accomplish in order to give you an answer.
I could, for example, program a dialog which allows you to
1. Paste text into a text box called "source"
2. Paste other text into a text box called "article"
3. Click "compare"
4. See a document which uses Word's native redlining to show you the comparison.
But you could just as easily:
1. Paste source text into a new, blank document you have saved called Source.doc
2. Paste article text into a new black document you have saved called Article.doc.
3. Run the native redline comparison on those two documents, and analyze the results.
And you don't need any coding what-so-ever. And this will work in version Word 2000 on up (if memory serves).
So... what version of Word are you using?
And what do you want to do after you look at the results of your "comparison" function?
Posting Permissions
Reply With Quote
