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://email@example.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *