AnsweredAssumed Answered

vrf GUID or Random Numbers

Question asked by VRFuser on Apr 6, 2004
Welcome back, Shawn!

Glad you got out of your communications hell. (Cable modem works very well where we live in Fort Collins)

> What about the .Net Framework? It offers the best of both
> worlds. It is way
> faster than COM and as Scott pointed out it's much better
> organized. It's an
> excellent gateway to the API but it does represent a rather
> steep learning
> curve. Not in it's use, but in it's namespace hierarchy. In the end,
> studying the tools available (containers and iterators, data
> types etc.),
> the standardized forms and functionality will make for
> easier, faster, more
> "Windows Standard" VEE applications.

Agreed.

The learning curve is why we have the System menu and the examplesDotNET directory in 7.0, to help you get started with some stuff that is relevant to T&M needs, though not directly instrument-related.

Things like "find my IP address" (System menu) and "send an email" (examplesDotNET). Or the very interesting UsingTerraServerWebService example, or its easier to follow companion UsingTemperatureWebService. If you need to draw arbitrary pictures, there's DrawOnBitmap. Etc, etc.

Hopefully they will help you see what value there might be to you in .NET access, so that you can go ahead and map out how to learn just enough of it to meet your needs. Or not, if .NET wouldn't help you right now.

Anyway, the tools are there.

Best Regards,



Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
> Sent: Thursday, April 01, 2004 12:11 PM
> To: PDL-LISTS,VRF (A-Lists,unix1)
> Subject: [vrf] RE: GUID or Random Numbers
>
>
> Oh boy. I was gonna shut up, but...
>
> These numbers are not GUIDs. The bits of a GUID are not
> random (which is
> exactly why they are not duplicated) though they do contain a "random"
> component - a GUID is truly a "GLOBALLY" unique identifier.
> It may seem
> petty to argue about what is and isn't a GUID, but the potential
> consequences of using one of these numbers as a GUID (in the
> way Windows
> uses them) are horrific. I understand you're using them as
> filenames - which
> won't hurt anybody. Just don't put that name in curly braces!
> All sorts of
> things could start going wrong.
>
> > Also, with these API things I'm always concerned about
> > differences across operating systems.
>
> This is the point I try so hard to get across: The lowest
> common denominator
> of any Windows PC is the Win32 API. That's half the reason I
> use it. You can
> never be sure what libraries somebody will have on any given
> computer. BUT -
> you can ALWAYS depend on having the base Windows libraries.
> These include:
> kernel, user, gdi, ole, advapi, mmsystem and comctrl as well
> as a host of
> others.
>
> With few exceptions, any standard Windows task you want to do
> via COM is
> doable with the Win32 API. In these instances, COM is a
> convenient wrapper
> around the API. It began life as a way to call functions that
> the brain-dead
> Visual Basic 2 couldn't.
>
> MS had pushed to make COM system-wide. To replace the API with an COM
> equivalent, but COM is far too inefficient and problematic to
> make that a
> realistic possibility. Some examples of these attempts can be seen as
> adjuncts to some API functions, like those beginning with
> "SH" for example.
> SHBrowseForFolder is the root function of all folder
> browsing, but it relies
> on the IMalloc interface, as well as others. Specifically,
> IShell. Therein
> lies a problem. You've often seen me say "shell version 5
> specific" and
> similar things.
>
> Fortunately, most of these versional nightmares are confined
> to the shell
> and don't affect the underlying OS. Core Windows (Win32 and
> Win64) remains a
> C-based API, and I'm eternally grateful for that. Once you
> get past the
> shell, there are very few versional differences. Windows XP
> is not a new OS,
> it's just Windows NT 3.1 with a different coat on and a few
> enhancements -
> most notably the driver architecture since Windows 2000.
>
> Unfortunately, most everybody is convinced that interaction
> with Windows
> means interacting with the shell, either directly by time-wasting and
> complex sequences of clicks, shifts, drags and drops and whatnot or
> indirectly by instancing and manipulating some COM object.
> This is most
> definitely not the case, though it is trending more and more
> toward that
> paradigm.
>
> The propagation of the GUI myth really ticks me off. I can type xcopy
> c:usrshawnmusic*.mp3 u: a *WHOLE* lot faster than I can
> navigate to my
> music directory with Explorer, type Ctrl+a and drag files
> over to another
> drive - which in my case isn't even visible in the left pane
> any more. I
> have to either scroll the left pane back to it before I drag
> or drag and
> wait for Explorer to realize that I want to scroll the left
> pane and wait as
> it chunks along, one directory per second or type Alt+e f and
> navigate to
> another drive or have my planned destination in the SendTo
> folder and type
> Shift+F10 n, arrow down to my drive and Enter. None of those options
> compares favorably with simply typing a command of 34 chars
> that takes about
> 4 seconds.
>
> The most efficient way to run the OS directly is via the
> command line, and
> indirectly via the Win32 API. If you need maximum horsepower, watching
> little sheets of paper fly from one folder to another or
> waiting for COM to
> call the API is not in your best interest.
>
> As far as GUID generation goes, the only and absolutely will
> work on any
> Windows NT 3.1, Windows 95 or later PC in the world way to
> create a true
> GUID is to call CoCreateGuid in Ole32.dll. Any other sanctioned way to
> create a real GUID calls this function. It only makes sense
> to call the
> function directly and not filter it through one or more layers of COM.
>
> The advantage of using Georg's method
> (Scriptlet.TypeLib.TypeLib) is that
> it's simple and you get a string. The disadvantage is that the TypeLib
> object is implemented in scrobj.dll, not a standard Windows
> component, and
> instancing a TypeLib object cascades into a host of other
> activities that
> have nothing at all to do with generating a GUID. The
> advantage of using
> CoCreateGuid directly is that it is guaranteed to work on any
> Windows PC in
> existence. The disadvantage is that you have to call
> StringFromGUID2 to
> convert the GUID to an OleStr, and WideCharToMultiByte
> (naturally, both also
> guaranteed to exist on any Windows PC) to convert the OleStr
> to a string
> that VEE can use.
>
> Sometimes you simply have to use COM because there's no other
> way. In these
> instances you have to provide for dll hell. Sometimes it's
> just easier for
> you to use COM even though you know what API calls are
> required. Here also
> expect dll hell to crop up unless you choose your COM
> interface carefully -
> an activity that requires years of component research and use to
> successfully execute.
>
> What about the .Net Framework? It offers the best of both
> worlds. It is way
> faster than COM and as Scott pointed out it's much better
> organized. It's an
> excellent gateway to the API but it does represent a rather
> steep learning
> curve. Not in it's use, but in it's namespace hierarchy. In the end,
> studying the tools available (containers and iterators, data
> types etc.),
> the standardized forms and functionality will make for
> easier, faster, more
> "Windows Standard" VEE applications.
> -SHAWN-
>
>
> ---
> You are currently subscribed to vrf as: scott_bayes@agilent.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list,  email "vrf@agilent.com". 
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Outcomes