> Geoff Harland wrote:
>
> <snip>
> > So unless anyone subsequently reports that they can create metafiles from
> > .DDB
> > files using the 'Windows File System' option by using the Export (to
> > metafiles)
> > command (which would imply that there is some issue with my PC),
> > I am concluding that this is yet another one of Protel 99 SE's bugs.
> <snip>
>
> Well, I haven't mentioned in my previous post that I use 'MS Access Database'
> storage option and I tested the Export command in such 'environment'
>
> So, I created new database with 'Windows File System' option and retested
> the Export command - the command seems to work the same way it worked with
> the 'MS Access Database' storage option - I mean it produces wmf files
> which seem to be usable.
> It was just a quick check.
>
> Regards,
> Wojciech Oborski
Thank you for your additional testing and feedback. Your experience indicates
that there could well be some aspect of my PC which is causing problems after
all (unless I have come across a defect of a "movable feast" nature, which is
not unheard of within the Protel/DXP/AD applications).
I had previously been inclined to surmise that .DDB files using the 'Windows
File System' option could be problematic, because after opening a .DDB file (of
such a nature) with a file name of Printing_Test.Ddb and a path of D:\Misc (and
thus a "full" file name of D:\Misc\Printing_Test.Ddb), the title bar of the
info box invoked after attempting to create the metafiles contained the text
string of 'Unable to write to D:\Misc\Root\Printing_Test.reg' (so the inclusion
of the subfolder with the name of 'Root' within that path made me suspect that
*not* using the 'MS Access Database' option could have been responsible for
that outcome).
Another thing which I have tried, but with the same result, was to log on as an
administrator user (rather than as a "Power" user as I normally do). (When I
previously used NT 4.0 on another PC, I always signed on as an administrator
user at the time, but since changing to Win 2000 on a newer PC, I have set up a
separate "Power" user account, and which I normally sign onto instead.)
But while there is still an outstanding mystery as to why I am currently unable
to create metafiles on my PC from .DDB files using the 'Windows File System'
option, I am not too upset about that situation. I still have no interest in
using that feature in normal circumstances, and the reason why I was wanting to
try out that command in recent times was to ascertain under which circumstances
any metafiles created by that command would contain misoriented text strings.
And after getting that command to work after opening a .DDB file using the 'MS
Access Database' option instead, I have now established that an associated
metafile is problematic whenever the 'Enable Font Substitution' option and the
'Mirror Layers' option have both been selected for the corresponding Printout
definition. (And the strings which are problematic in that regard are any
strings which are depicted within the metafile in an unmirrored form, and whose
Rotation property within the "source" PCB file is neither 0 degrees nor 180
degrees nor 360 degrees.)
This defect of the Export (to metafiles) command occurs under the same
circumstances that defects of a similar nature occur within previews of
printouts, and within any printouts that are actually created from any .PPC
file.
OTOH, when the Copy (to the Windows clipboard) command is invoked instead (one
way being by the menu entry of 'Edit -> Copy', which results in the clipboard
being loaded with an image of the preview of whichever Printout definition is
currently focused), there is once again a defect of a similar nature - but
rather than also similarly afflicting Printout definitions for which both of
the 'Enable Font Substitution' and 'Mirror Layers' options have been selected,
it *instead* afflicts Printout definitions for which the 'Enable Font
Substitution' option has been selected and the 'Mirror Layers' option has *not*
been selected.
And for those who are interested, the Copy (to the Windows clipboard) command
is still similarly afflicted within the final (SP4) version of AD 2004, but
*both* *unmirrored* Printout definitions *and* *mirrored* Printout definitions
(for which the 'Enable Font Substitution' option has been selected) are
afflicted by this defect. OTOH, that particular defect has been *totally*
purged (within the same version of AD 2004) from all previews of printouts, all
actual printouts themselves, and all metafiles created by the Export (to
metafiles) command.
Maybe somebody can report if has since been rectified, but I am picking that
the Copy (to the clipboard) command is still defective within the current
version of AD 2006. (I can't test this myself, as I don't have any copies of
any version of AD 2006.)
What is highly disturbing about this particular defect though is that it took
so long to rectify it within previews of printouts, actual printouts, and
metafiles created by the Export command, and that it still hadn't been
rectified within images copied to the clipboard by the Copy command when the
final SP for AD 2004 had been released. It should not have taken too much
effort to rectify that particular defect - and it *should* have been rectified
even before *any* version of the PcbPrint server had ever been released to
anyone external to Altium. Printing from PCB files is functionality of a "core"
and critical nature, so it defies belief that it took so long for this defect
to be "mostly" eliminated from the software.
And quite frankly, given that there was so long a delay in rectifying a defect
of a relatively trivial nature (as far as the effort required to actually
rectify it is concerned), but also having a distinctly non-trivial impact (as
far as having its detrimental impact upon core functionality is concerned), it
would not be at all surprising if Altium's more astute customers were given to
wondering just how many other aspects of the software are similarly defective,
and just how much it can be "trusted" to not "goof up" on any details of a
critical nature. I have previously opined that spelling mistakes undermine any
efforts made to market the software (as customers could infer that if Altium
can't manage something as straightforward as spelling words correctly, then
whether they could competently manage any other tasks of a more demanding
nature). And when customers purchase software which contains defects which
shouldn't have even been seen by beta testers (let alone by
them), and those defects are not subsequently rectified in a timely manner,
then that doubtless also has a detrimental impact upon Altium's efforts to
market their software.
I don't think that the software is totally vile, and some aspects, such as
customers being able to totally customise the resources (menu entries, toolbar
buttons, and shortcuts) associated with each server, are definitely worth
raving about. Regrettably though, I also consider that there are far more
defects within the software than there should be, and I also find it incredibly
frustrating that it takes so long for many of those defects to be rectified
(and in some cases, have probably *still* yet to be rectified).
Regards,
Geoff Harland.
_________________________________________________________________________________
Yahoo!7 Mail has just got even bigger and better with unlimited storage on all
webmail accounts.
http://au.docs.yahoo.com/mail/unlimitedstorage.html
____________________________________________________________
You are subscribed to the PEDA discussion forum
To Post messages:
mailto:[email protected]
Unsubscribe and Other Options:
http://techservinc.com/mailman/listinfo/peda_techservinc.com
Browse or Search Old Archives (2001-2004):
http://www.mail-archive.com/[EMAIL PROTECTED]
Browse or Search Current Archives (2004-Current):
http://www.mail-archive.com/[email protected]
