Friend procedure can be called from anywhere in the current project, but not from outside it.
If my project is a single project which is a Standard EXE, I don't have to Friend procedure, but use Public procedure, is it right?
If not, how the Friend procedure is used in a project?
Last edited by jdy0803; Jan 12th, 2015 at 12:25 AM.
Friend is meant to be used in server library projects, to allow private communication among the classes (including Forms and UserControls, which are kinds of classes) inside that project.
Nothing prevents you from doing the same thing within a Standard EXE project, but it loses meaning since there is no client-server boundary to protect from tampering. But it can still be good practice to use Friend in a Standard EXE where the logical intent is the same.
A common usage might be a "class factory" singleton class, which is used by client programs to create instances of other "non-creatable" classes. The factory class can call Friend members to initialize the created instances. Most of which only makes sense in a server project (ActiveX EXE, OCX, DLL) where you get boundary protection, but the same paradigm applies even when you don't.
There is another significant usage of the Friend modifier when applied to a class member.
In a class, you can not use public UDT's as parameters to subs or functions, nor can you use use them as the return type of a function or a property. To use UDT's in as class, you must have the UDT declared as Private inside the class and for usage inside that class.
When you use Friend as a modifier to a Sub or Function or Property of the class, you get access to Public UDT's declared outside of the Class. They can be passed as parameters or be returned by a Function or Property.
And a couple more points of interest regarding Friend declarations:
1) Can't be used in bas modules
2) Can't be called by VB's CallByName
3) Can't be called late bound, though I think I've seen a patch for that on this site
Another use, though very specific, would be something along the lines of what dilettante posted. To use a single VB class as both an interface for use with the Implements keyword and double as a stand-alone instance of that class. In that scenario, the class ...
a) Creates all needed Public method/property stubs to be implemented by VB by declaring Implements [ClassName]
b) Creates Friend subs/functions/properties that would be used if the class were created as a stand-alone instance, as needed. Friend methods are not Implemented and any code in Public methods is not run when the class is Implemented, only when it is instantiated on its own.
Maybe more than you wanted to know?
Insomnia is just a byproduct of, "It can't be done"
There is another significant usage of the Friend modifier when applied to a class member.
In a class, you can not use public UDT's as parameters to subs or functions, nor can you use use them as the return type of a function or a property. To use UDT's in as class, you must have the UDT declared as Private inside the class and for usage inside that class.
When you use Friend as a modifier to a Sub or Function or Property of the class, you get access to Public UDT's declared outside of the Class. They can be passed as parameters or be returned by a Function or Property.
This is a confusing post, but it does make a point.
It is confusing because when you violate the scope rules using flat UDTs the errors tell you that you need a "public" UDT. This is entirely unrelated to your UDT being declared as a "Public Type" in a static module, it means "published" as in "is declared in a type library" such as those defined within classes in a separately compiled server library.
These are Automation VT_RECORD types and not really the same as a dumb, "flat UDT" which is what the static "Public" ones are. A type of VT_RECORD can be marshalled and a dumb UDT cannot, which is the critical difference and the source of the exception that can result from trying to misuse them.
Best solution: stop, stop, STOP relying on the use of UDTs so much. You are just going to get wound up in your own underwear and end up posting the 100,000th thread here asking "Why does it say my UDT needs to be public, it already is?"
UDTs were already dead in VB6 except for use as a struct stand-in for making API calls or for LSet-based "casting."
It appears there's one more difference between Friend and Public procedures: Friend procedures are invoked much faster than the equivalent Public procedure.
On Local Error Resume Next: If Not Empty Is Nothing Then Do While Null: ReDim i(True To False) As Currency: Loop: Else Debug.Assert CCur(CLng(CInt(CBool(False Imp True Xor False Eqv True)))): Stop: On Local Error GoTo 0
Best solution: stop, stop, STOP relying on the use of UDTs so much. You are just going to get wound up in your own underwear and end up posting the 100,000th thread here asking "Why does it say my UDT needs to be public, it already is?
Nahhhh... The Friend modifier and UDT's are totally useful. Without it, my CAD class could not communicate with my GDIP core library, my FFT class could not communicate with my complex math library, my DataAcquisition class could not communicate with my WAV core library, the list goes on quite a bit : my mechanics core lib, physics core lib all make use of Public UDT's callable from Friends members of processing classes. I used to go through loops and hoops doing all this stuff in VB4, but since VB6 and Friends, my programs are leaner, faster, more reliable, use less ressources and more importantly faster to write and easier to maintain, without having to go the trouble of pumping up TypeLibs.
By the way, the error VB splashes in your face about Public Types is somewhat misleading. VB6 reference better explains the usage of UDT's with friends member, so I go by the MS-book.
Besides, UDT's are no more dead than XP is. Most of my customers are still using XP Toughbooks.
Impact of malware protection on supported and unsupported operating systems
One question I hear a lot when discussing unsupported versions of the OS is "So, won’t antivirus help protect my computer?" We absolutely encourage everyone to use real-time antimalware to help protect themselves against cybercriminal activity. In fact, the latest report shows that during the last quarter unprotected computers were 7.1 times more likely to be infected than protected computers.
That said, our data also tells us that running antimalware on out-of-support systems is not an equitable solution to protect against threats. The following chart compares the monthly infection rates for protected and unprotected computers on Windows XP SP2 and Windows XP SP3 in the last half of 2012 (this data for Windows XP SP3 was reported in the "Running unprotected" section of SIRv14).
The data shows that protected systems on Windows XP SP2 are twice as likely (2.2 times, to be exact) to be infected in comparison to protected Windows XP SP3 computers. Unprotected computers show a similar trend: you’re 2.5 times as likely to be infected on Windows XP SP2 in comparison to Windows XP SP3 when neither have up-to-date antimalware protection.
So I suppose we have you and your supposed "customers" to thank for the continuing and growing plague of zombied XP systems spreading malware and spam.
So I suppose we have you and your supposed "customers" to thank for the continuing and growing plague of zombied XP systems spreading malware and spam.
Windows XP is a threat to everyone.
Oh man.. this is complete gibberish. If you want to blame someone, go for the hackers and MS who has sold us their "Safe" NT platform for years and years, with hundreds upon hundreds of security patches without making the systems secure ever.
But that's besides the point. In the field of heady-duty machinery, an oil analysis program (just one example) costs in excess of $30K. It will take more than Ipods and MS-WIN's flavour of the month OS to replace perfectly working stations in maintenance dept of Fortune 500 companies. As a matter of fact, many of those companies buy brand new PC's and revert the OS back to a 32 bit versions to protect their investment of legacy sofware that is very hard and expensive to replace. Lots and lots of 16 bit software still running out there. CNC machining another case in point. Hundreds or thousands of computers around the world still pushing circa 1980 HPGL and G-code to punch holes and cut material. These just don't need Megahertz PC's nor the internet nor malware protection and they are replaced by the same when they fail.