At 06:48 AM 10/27/01 +1000, Ian Wilson wrote:
>I would *not* want the ini/rcs etc files made binary and stored in other 
>than simple files.  But it would be nice if they were not stored in the 
>windows folder, even one set of settings for all users but stored in a 
>dedicated folder in the Design Explorer folder would be heaps better.  Any 
>one with comments on this?

Sure.

(1) Yes, I agree that the initialization and resource files should not be 
kept in the Windows folder. For one thing, it makes uninstallation a tad 
more difficult, causing frequent questions to this list about why certain 
crashes repeat even after Protel is reinstalled.

(2) The initialization files should be kept with the executables, as with 
most programs.

(3) Tango DOS had a system where a copy of the .ini and .dfn files was kept 
in the [Tango] PCB executable folder (the former controlled stuff like 
current loaded file, and the latter controlled pad definitions, gerber 
definitions, and other stuff that might be design-specific). But if Tango 
was executed from a current directory other than the executable directory, 
PCB would look in the current directory for the initialization files. So, 
if you wanted to do so, you could use a separate .ini and .dfn file for 
each design simply by keeping each design in its own directory with its 
corresponding .ini and .dfn files.

I'd suggest that a customization file be a part of the .ddb. 
Initializations that are shell-related would have to be in a separate file, 
as now. But customization that relates to a specific .ddb would have 
control file(s) within that .ddb. These files would automatically be 
created from the default files when the .ddb is created, or the first time 
that a related server is loaded. If the file is in the .ddb already, this 
would be the file used. The default file would not be edited when one 
customizes; instead, the specific .ddb file would be edited. To change the 
*default* file, one would edit the corresponding file from within the .ddb, 
either through the customization tools which already exist, or through the 
text editor, to what one wants and export it. Or a default file from 
somewhere else could simply be overwritten outside of Client.

I am aware that there could be complications, but I think that they could 
be addressed and the problems solved. We should be able to customize the 
environment for each design database, if we wish.

Frequently I send a file to a client who is not so familiar with Protel. We 
are talking about, say, a PCB, and we both have it up on the screen. Quite 
often, the client will refer to or ask about a primitive by its color. Of 
course, since the colors are not part of the .ddb, he may have (and usually 
has) different colors than mine. He should be able to see what I see, 
exactly. In Tango, to accomplish this, I would simply send the pcb.ini file 
to the client, tell him how to change the video driver -- because this was 
DOS and Tango had a different driver for each make of video card -- and the 
rest would work fine. Because this file would be kept separately from his 
regular default file, he would be back to what was familiar to him when he 
worked on a different design. And I always archived the .ini and .dfn files 
with a PCB file, so the gerber setups, for example, would be the same the 
next time gerber was generated. Protel accomplishes this latter task with 
its database and CAM control files.

Tools for sharing customizations should exist. It should be easy, not 
complicated.


[EMAIL PROTECTED]
Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to