VXCMD_Client_Classic_MC

[Ken Ray]

> Ken, the entry points into externals are normalized per API. The 
> resource name is just an external binder. Try it out. Rename 
> Valentina to Valentina2. Any call to valentina will fail. But if you 
> change your transcripts to use valentina2, they should work fine 
> again. Or so they should :)

Well, perhaps that works with Classic or Carbon, but it doesn't work
with Mach-O. The reason is that the binding happens not as resources
inside the resource fork of our app, but as DLLs that get linked to with
the "externals" property.

So the "local" Valentina external is called "VXCMD_Macho_MC" and the
"server" external is called "VXCMD_Client_Macho_MC". Both of them get
calls through the function name "Valentina". So if I link both externals
to the same MC stack, when I call on Valentina(...), which external gets
used? In my experience, MC will pick one over the other (I think it goes
by alphabetical order), but regardless, I can't link both externals into
the same stack. 

So in my app right now, I have two separate stacks, each one linked to
its own external, and then a login dialog in our product determines
whether the user wants to access a local DB or a server-based DB. And
*then* I connect to the proper stack and are able to use the right
external. But it's a bit of a pain...

> Ruslan, having to use a different valentina call for local and server 
> activities may actually be a good approach for coding.
> 
> get valentina ("SqlSelect",dbName,query)
> get valentina_server ("SqlSelect",dbName,query)
> 
> This way it is easy to keep track which code works locally and which 
> works remotely, particularly for programs that support both modes in 
> parallel. While most Valentina functions are the same, they are not 
> exactly the same and server has more of them. It is also easy to 
> switch from local to remote and vice versa.

I totally agree. :-)

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/