Closed Bug 66920 Opened 24 years ago Closed 24 years ago

Embedding APIs need an MFC test harness

Categories

(Core Graveyard :: Embedding: APIs, defect)

x86
Windows NT
defect
Not set
normal

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.
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
*** Bug 66918 has been marked as a duplicate of this bug. ***
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)?
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.
r=valeski
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
That's correct.
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.
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?
Sounds good: I vote for keeping mfcEmbed as the main one because of its completeness.
should this be closed?
This bug's fixed now.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
marking verified. mfcembed is functional as an mfc-based test harness.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: