At 07:59 AM 2/1/2002 +1100, Ian Wilson wrote:
>On 10:45 AM 31/01/2002 -0500, Abd ul-Rahman Lomax said:
> >I used MYOB, an Australian accounting program, for my wife's business. It
> >does data import in this way. Nice feature, one of the reasons I bought the
> >program.
>
>Well then you will very aware of how some Australian software companies 
>can loose the plot totally and provide absolutely terrible and 
>inconsistent user interfaces - MYOB is a classic in this regard - but do 
>not get me or my HCI/ergonomics expert wife involved on this topic.

MYOB's interface is terrible. Except the import process is *usable*. 
Without it, forget converting business data from another program.

>Protel is a dream of consistency and the user interface is very well 
>designed compared to MYOB.

My point was not to compare Protel and MYOB except within the narrow realm 
of importing data. MYOB could also be improved in that regard as well.

>On the other issue Spread Export/Import.  I will leave to others to make 
>comment if they can be bothered.  I have made my points and at least some 
>I stand by.  I agree with Dwight - hopefully Protel will not think that 
>Abd ul-Rahman's (worthy) extensions to the spread import facility must be 
>provided before we get the incremental improvement of persistent handles.

Well, I think persistent handles would be useful as long as it is possible 
to discard them and still do imports. However, as Mr. Wilson has already 
noted, true GUIDs could be quite cumbersome. I'm pointing out that what we 
need is the ability to work with data beyond a single session with 
everything kept open. GUIDs could certainly help with this, but there are 
also other ways to accomplish the same end. Being able to define a key 
field or fields would, in fact, be enough. Simply adding an additional 
field to primitives, locked by default but unlockable and editable, would 
provide almost everything. A process would stuff this field with a GUID if 
that is what is wanted. This might even be made default behavior. But all 
the other ways of working that I describe could also stuff that field 
according to calculations, thus expanding the utility for those admittedly 
few times that such is needed, without overburdening the program.

In other words, give us GUIDs, but let us -- with warning -- edit it. For 
example, if we want to use reference designators to link the spreadsheet 
data with the schematic data, we could simply copy the designators into the 
GUID fields.

But I think that Mr. Wilson might want a persistent GUID that cannot be 
edited away. And I would argue against this fairly strongly. It fixes what 
is arbitrary, useful for one narrow purpose -- an admittedly common 
purpose, in the way for other purposes. We do *not* have permanent links 
between Schematic and PCB and for good reason. We have *persistent* links, 
which is something quite different, and we have a method of re-establishing 
links if they don't exist or have been damaged, albeit a fairly primitive 
method, at least it works most of the time.

This discussion has revealed some ways that relinking might be 
accomplished. GUIDs could help with relinking in some cases and could 
hinder it in others. We *do* need flexibility here. This flexibility can be 
"under the hood," it need not and should not overburden the beginning user.

We can get what I want and I think what Mr. Wilson wants, absent the 
straight jacket, if there are a few fairly simple new characteristics to 
Schematic: (1) A GUID is created whenever a symbol is placed. (2) This GUID 
is stuffed into an ID field. (3) The ID field takes the place of the 
present handles used to link spreadsheet exports and the open Schematic. 
(4) There is a facility for assigning GUIDs to parts that don't have them. 
This will optionally assign all new GUIDs or it will only assign them to 
parts with empty fields. (5) There is a facility for transferring the 
reference designator to the ID field, or sheet/coordinates, or other kinds 
of data. (6) The ID field is exported with the spreadsheet and can be 
edited if needed. (7) Any edits to the ID field would require bypassing 
warnings of some kind, such as field lock in the spreadsheet or a warning 
and approval in Schematic. (So, for example, item 4 would not operate 
without a warning and approval.)

[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