Closed
Bug 66920
Opened 24 years ago
Closed 24 years ago
Embedding APIs need an MFC test harness
Categories
(Core Graveyard :: Embedding: APIs, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: chak, Assigned: chak)
References
Details
Attachments
(2 files)
The current winEmbed embedding sample uses Win32 SDK style C/C++ code to
demonstrate the embedding APIs.
Since most commercial apps these days use MFC there should be a sample app which
shows users how to use the embedding APIs from within MFC.
Comment 1•24 years ago
|
||
Chak, can you post your code here for review? If it's too massive, email it and
I'll put review here.
Assignee: valeski → chak
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•24 years ago
|
||
Comment 4•24 years ago
|
||
The code looks good - clean, well organized and commented. Also, this sample has
much more functionality than winEmbed.
One problem though - Some of the files in the project have names > 31 chars
long. This causes a problem for the Mac. MacCVS will have to truncate the names
when checking out the files. Can you shorten some of the long names down to 31
chars or less (including suffix)?
Assignee | ||
Comment 5•24 years ago
|
||
Assignee | ||
Comment 6•24 years ago
|
||
I also made the following changes in addition to what Conrad suggested:
1. Modfd. MfcEmbed.cpp so that we properly shutdown the hidden wnd. when the
last window is closed. This fix also takes care of not closing the app but just
closing all the frame windows in the case of a profile switch
2. Minor re-org of InitInstance() in MfcEmbed.cpp - moved code into separate
functions for creating the hidden window and profiles - just to keep it clear
3. Modfd. ValidateProfileName() in ProfilesDlg.cpp so that we do a
"if (profileName.FindOneOf("\\/") != -1)" instead of
if(profileName.FindOneOf("\\/")) since FindOneOf() returns a "-1" if the chars
are not present and the if always succeeds even if the "/" or "\" are not present.
Comment 7•24 years ago
|
||
r=valeski
Comment 8•24 years ago
|
||
assuming...
1. your adding a mozilla/embedding/tests/mfcEmbed dir, and dropping these files
in there.
2. you're *not* connecting this to the main build (yet).
3. you add binary files using the binary add flag ("cvs add -kb filename").
sr=valeski
Assignee | ||
Comment 9•24 years ago
|
||
That's correct.
Comment 10•24 years ago
|
||
I think that the file winEmbedFileLocProvider.cpp should be moved out of the
mfcEmbed dir and into a place (and built as a static lib) where both mfcEmbed
and winEmbed (in the near future) can use it.
Assignee | ||
Comment 11•24 years ago
|
||
Judson's current thinking is that we want to maintain a single "main" sample app
for Windows - winembed or mfcembed - so as not to duplicate our efforts.
We probably should decide which one it is first, then, the
winEmbedFileLocProvider.cpp file can live in just that one place?
Comment 12•24 years ago
|
||
Sounds good: I vote for keeping mfcEmbed as the main one because of its
completeness.
Comment 13•24 years ago
|
||
should this be closed?
Assignee | ||
Comment 14•24 years ago
|
||
This bug's fixed now.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 15•24 years ago
|
||
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
Comment 16•24 years ago
|
||
marking verified. mfcembed is functional as an mfc-based test harness.
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•