realbasic-nug
[Top] [All Lists]

Re: International Libraries on Windows

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: International Libraries on Windows
From: Aaron Ballman <aaron at realsoftware dot com>
Date: Tue, 06 Dec 2005 09:14:44 -0600
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <5c8121ef0512060615s40d74c7ep8afdc596005274db at mail dot gmail dot com>
You have a windows app, it has international users, and it has a 3rd party
library you need to use.

Yup, been here, done that.

Windows + libraries means you have to use hard-coded paths.

What gives you this idea? You should almost *never* use a hard coded path since that means your application is going to break very easily. For instance, user 1 may have Windows installed on their C drive. User 2 might have it on their D drive (very common).

International
means you aren't sure what those paths are on the end-users system. For
example, C:\Program Files\<your_software> doesn't exist on French, Italian,
Dutch, Arabic, etc. computers.

What do you do? Or am I the only one running into this situation?

You're going about the issue wrong. Libraries come in two forms -- public and private. Public libraries are ones that all applications can use because they're installed in a known path (like the system32 directory). Private libraries are ones that are only meant to be used by the author, and they're stored directly next to the executable (or within a subdirectory of it).

If you're using a public library, no path is needed. If you're using a private library, then you should get permission from the original author to use it and include it with your application as a private library.

Make sense?

~Aaron
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

<Prev in Thread] Current Thread [Next in Thread>