> Yeah, you can "REPLACE ALL classloc FOR... " in a .vcx table. One table
> at a time.
>
>
Yeah, that's not prone to error.
Oh, everything I do is prone to error. :) It's just that with every rep the
error rate drops... a little.
Or, you could use HackCXPro:
http://www.whitelightcomputing.com/prodhackcxpro.htm
No offense to Rick and his great tools. Usually though I treat these things
as a learning opportunity. That's why I went ahead and rolled my own
projecthook to automate this stuff. It works pretty well.
Of course, not everything the Project Manager does is hook-able; it does
stuff with the file list before we get the first hook opportunity, and it
apparently also does other things with classloc fields behind the scenes.
So as I've tested my framework/project relocations, I've found that an ever
growing string of relative-path symbols gets added to the classloc field, a la:
..\..\..\..\..\path\to\my\goodies
Every time my code updates the classloc value it strips those out, but they
keep getting put back. <shrugs>.
It doesn't seem to have any effect on the ability of my projects to
function, or compile. So onward and upward... I won't need the feature that
much once I get done revamping and testing the framework.
to address the original question, when we (the old we, Blackstone,
'95-2000, RIP) first started working with MaxFrame, we added two layers of
abstract classes to the hierarchy: Blackstone-level for our standard means
of overriding the framework for customizations we came up with, and
client-specific to allow an individual client to have specific
customizations like resizers or audit trails. Seemed good in theory :) Was
rarely put into practice, and introduced some funny problems, especially
when dealing with composite classes: for example, a MaxFrame container that
contained MaxFrame images and buttons would be subclasses and become a
Blackstone container that still contained Maxframe images and buttons. It
got even gnarlier with grids and such.
Yup. I've been bitten by subclassing when I should have composed many times.
As a general rule, adding empty classes, containers, pages and methods
"just in case" you're going to need it in the future is an anti-pattern of
premature optimization. When you finally do need it, it inevitably needs to
be in a different structure than what you predicted anyway. Better to do a
clean refactor when its needed that to add a lot of overhead you may never
need.
I'm a big fan of YAGNI: http://c2.com/cgi/wiki?YouArentGonnaNeedIt
Like Christof said, I put in the abstract classes because "it's good OOP
practice" at a time when I lacked enough experience to make my own judgment.
So now I'll rip 'em out.
Thanks Ted. It always helps to get your perspective.
Ken Dibble
www.stic-cil.org
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
