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
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
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.