That structure is pretty common as a ByRef value return of a function. As
you know, functions are unique in that they return a result. In other
languages, there is no such thing as a subroutine as all code  structures
return a result. The particular routine  declaration you're referring to is
bubbling up an internal result and that is common for DLLs to do
(including API references).

The Public declaration in this case also makes the call possible from
outside the DLL itself. This is often called  an Export from the DLL. It
may have other internal calls defined  as Private and these won't be
accessible from external applications.

http://support.microsoft.com/kb/142840/EN-US/ might be helpful because it
explains what VB expects to work with when a DLL exports a function. And
I'm betting you're already aware of this end-to-end tutorial about writing
VB code to control hardware but I'll add  it anyway:
http://www.boondog.com/%5Ctutorials%5Cdlltutor%5Cdlltutor.htm. Also, here
is one of my favorites because it comes as close to how I learned as
anything I've seen: http://www.thevbzone.com/secrets.htm

And from all that, here's a basic rule set to have in mind about returned
values, etc. DLL exports require a single method for accessing them and
that is the use of a Private Declaration pointing directly to the DLL. The
behavior of such a call is similar to that of referencing a COM object (by
far, the most common way of accessing an export within VB). When a ByRef
variable is passed or retrieved, what is really happening is the exchange
of a pointer to a location in memory where the calling  App and the called
DLL store information. This location is passed back  and forth By Reference
to that location.

When a ByVal variable  is used, the caller and called don't share the
location in memory. Instead, the called DLL gets the value it stored in
memory and passes the result back to the caller. This means, of course,
that only one of the partners in this relationship can change what's in
that memory location.