WF/WF2 with less flaws?

Hello folks,

As we all know, Pro/E could be a very powerful tool, if there weren't so
many flaws in it's mathematical core (e.g. skeched curves will always jump
and cause errors on the subsequent features, if a dimension is changed)

For WF and WF2 did they turn their attention to the correction of this flaws
or only to catching up with the competition in terms of an intuitive user
interface in their new WF and WF2 ?

Thanks for your comments!

best wishes,

Michael

 

As we all know, Pro/E could be a very

Sure they did. No they didin't.

How about isolating one of the flaws, get an eval version, test and let us know
how if it works better?

Seriously, this sounds like something a used car salesman would put on the
table. If there's some specific "mathematical flaw" or, maybe, user problem
you'd like to discuss...?

 

What? Huh? Sketched curves will always 'jump' if a dimension is
changed. IF you've constrained a subsequent feature to the feature
which you've just modified, it is going to be affected. That's the
whole point; it is SUPPOSED to influence subsequent features. That is
why the call it a history-based, parametric modeller. That's why the
model tree has a hierarchy, not a flat structure. If your subsequent
features fail, that is your fault for not building in the proper
DESIGN INTENT. ProE is working exactly as it should, and how a
designer should expect it to.

Just because Solidworks, et al, does not enter a resolve mode when
you've botched something up (it just puts a red flag on the features
that have problems and freezes them) doesn't mean that poor design
intent has not screwed up that model too. It is to their detriment
that they do not essentially force the designer to fix the mistake.

I am not saying ProE is perfect; in fact it is far from it. But it's
problems are really more to do with the GUI than the core. And I
believe that most of the GUI problems are directly tied to the fact
that PTC has committed to maintaining both a Unix and a Windows-based
version of the same piece of software. This has forced them to have
to write their own libraries (.dll files) instead of using the 'stock'
Microsoft ones so that it is compatible on Solaris/Linux/HP-UX/AIX and
Windows 2000/XP/XP64. And to be frank, they're not very good at
writing their own libraries. Every time Microsoft decides to alter
some of the 50 million lines of code underpinning Windows, a myriad of
unintended consequence ensue. One has only to look at the problem of
window-flipping with the Menu Manager to see its effect. Sometimes
everything's working fine and then the next datecode comes along and
you're hunting for that dialog box that is underneath the model window
and won't come to the fore. Native Windows libraries do not suffer
this problem because they are all 'click to select' not 'point to
select' like Unix Motif-based systems. There is an inherent conflict
in how these two systems respond to cursor movement and PTC is
struggling to straddle the fence.

The same goes for fonts in detail mode. Since they can't rely upon
Windows .ttf files (since they don't exist in Unix), they are somehow
scanning them on the fly and rasterizing them. If you don't believe
me, print a Solidworks drawing to a PDF file and do the same with
ProE. You can select the text AS text in SW but in ProE, it is all
'image'. And don't even look at the file size of the ProE PDF file;
setting the detail font to Times New Roman produces a truly humongous
PDF file.

Regards