Re: Variant arguments & com function calls

Hi Robert

Robert Hastings wrote:
> That makes some sense, but why not rename COMError to Win32Error, JniError
> or StructuredExeceptionError since you don't have to be doing anything COM
> to raise this type of error. You only need to be doing JNI calls to have the
> potential to cause an ACCESS_VIOLATION.

You are right. It seems quite a few of the naming conventions in Jawin
could be discussed, and this is definitely one of them. I also think
that COMException is used for the Win32-calls (see the
GenericStub#win32Invoke()), which is also clearly wrong. So if you want
to refactor/change names for some of the classes in Jawin to give them
more intuitive name, you have my full support.

Also I think now is a good time to do such API breaking changes, since
we have anyway declared the CVS-version to be a major bump.

Some other breaking changes, I have considered to make Jawin as simple
and intuitive to use as possible, was eg. to move the Ole32 class out of
the org.jawin.win32 package, and into eg. the org.jawin package (or
create a delegator class in this package). This way we could entirely
hide the org.jawin.win32 package from users of Jawin (as I think the
rest of the classes in the package is only used by the typebrowser or
internal in Jawin). And that would give the user, one less package, and
20 less classes to worry about.

I would also remove the org.jawin.tools and org.jawin.event packages if
possible (until now, I haven't found any places where they are used or
they are terrible out-dated, see the javadoc for these packages for
further information). Do you know what the exact purpose of these
packages are?

Best Regards
Morten