Re: MS/BCGSoft FeaturePack a one big [embarassing] hack and developer's nightmare?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"divya_rathore_@xxxxxxxxx" <divyarathore@xxxxxxxxx> wrote in message
news:d77dd40d-68cb-4f28-9090-670e4791ed3c@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hmm.. Feature Pack is not really a plugin, I understand. So you need
to do a significant amount of code writing for sure.

My suggestion:

1. MSDN has a tutorial on adding Feature Pack controls to older MFC
apps. Try with that. Once you fail (well.. unsatisfied,
anyways) ;) ..go to point 2.

2. Make a new project with same name and try to perform a code merging
from the new code to older one. Win Merge could be a good utility but
then perhaps you already have a favorite one. See if that helps.. once
you have the flavor of Feature Pack, one gets accustomed.

Do share your experiences!
I am working on one as well.. but it is small and hence am doing
everything afresh.

warm regards,

Divya Rathore
http://divyarathore.googlepages.com/fftwpluginforimageapprentice.htm

Thanks for the reply. I've gone through the steps you have mentioned many
times. The problem is that if your app is a bit more complicated on the UI
side (e.g. explores some of the more advanced features/internals of MFC)
then porting is a hell. I find it very frustrating that most of the BCGSoft
controls 'pretend' to be classic MFC controls but they are not. I've run
into many methods that compile find (i.e. pretend to be implemented) but do
nothing. So the process of filtering out those fake and useless methods and
replacing them with something useful is very tedious, frustrating, and time
consuming.

For example, if you ever used CDocument::GetDefaultMenu() then you need to
forget about it in the FeaturePack. The method is still called by the
framework but it does nothing.

Another example would be CMFCToolBar. You could simply substitute your
existing CToolBar with the new one (e.g. by #define) and your code will
compile. That does not mean that it'll run as the old one. For example, if
your code sets TBSTYLE_LIST and TBSTYLE_EX_MIXEDBUTTONS on a toolbar,
inserts buttons with text using SetButtonStyle()/SetButtonText() etc. your
code will compile fine (i.e. methods are there) but you will not get
expected results. I finally figured out that you should use
SetToolBarBtnText() instead. But it appears that there is no way of placing
button's text on the right side - i.e. text will always appear at the
bottom. So, I have yet to figure out how to create a toolbox-like toolbar
docked to the right side (i.e. like toolbox in VS dialog editor or a toolbox
in Axialis IconWorkshop). This is so simple in classic MFC. BTW, docs on
FeaturePack samples that VisualStudio demo has a toolbox but I could not
find it in the sample.

Yet another example. I have a comboboxex with images and text inserted into
a toolbar. I don't think I can port it to the pack - at least not without a
lot of coding. CMFCComboToolBarButton does not have SetImageList() like a
regular comboboxex so I thought that I could derive my own class from
CCMFComboToolBarButton and override its virtual method CreateCombo().
First, VS wizard generated a code that would not compile without
modifications (remove MESSAGE_MAP related stuff). Then the code compiles
but it does not run - need to replace _DYNAMIC with _SERIAL. The next step
would be to override relevant methods that deal with combobox. I might get
back to it later, if ever.

In general, the pack is not mfc. Instead it looks like a broken mutant of
mfc. If you stick to code as seen in demo projects then you might be OK.
If you try to build on your experience from classic mfc then you are in a
big trouble.

I finally decided to gave up on porting. Not worth the time and
frustration. I might come back later and give it another try.

For me the following are immediate show stoppers. If you (or anyone else)
could give me a hand then I'd really appreciate it:

1) How to create a toolbar with buttons that have text on the right side
(i.e. like toolbox in dialog editor) and dock it to the right side of the
frame? Again, in classic mfc you could accomplish this with TBSTYLE_LIST
and TBSYTLE_EX_MIXEDBUTTONS.

2) How to prevent menu bar from being dragged off the frame? Removing the
grip does not prevent it.

3) How to disable UI controls from being serialized to/from the Registry?
This would help a lot during development/debugging. As it stands now, I can
never be sure if what I see is a result of code changes or stuff lingering
in the Registry.

Thanks,
Bogdan










.

Quantcast