Multi-page application in Silverlight for Windows Embedded 7 - c++

I'm trying to develop an application in Silverlight for Windows Embedded 7, which uses C++.
I was able to run a simple page with a button, which calls another function (a simple Hello world message box).
The great question here is: how can I make a function display another page, defined in another XAML file? All the examples I found online, and even in Microsoft resources, uses a single XAML file with everything done inside it.
Thanks in advance!

I'm a student who is suffering from the same problem now. Hope there's someone to help us solve it.
I have searched and found that FRAME is not supported in the SWE.
I have found an alternative way to solve this problem but I'm not familiar with C++ code.
If you knows how to program in C++, would you please read through this and teach me a bit?
Thanks so much.
You can search for"Create a Custom User Control in Silverlight for Windows Embedded".
You'll found a PDF file released by Microsoft.
With this way you can create a custom user control to hold your "multi page".
I have done this step, and with the control I created, I am able to "hide" and "show" it in order to achieve the "multipage" effect.
In my User Control, I have some more buttons to let users to click. However, from the mainpage which hosting the user control, the buttons inside cannot be detect.
In the PDF tutorial they teach how do we call out the methods in the custom control, but I don't understand the C++ code.
If you can get the user control done make the controls in your custom control function correctly, would you please tell me? thank you.

To do multi-page applications, you need multiple xaml files. Not sure what the Microsoft tutorials you found were referencing, but i am developing an application now which has more than 20 different pages or screens. You need to design the layouts in XAML/ExpressionBlend and then using event handlers and pointers to the XAMl, implement the views in the C++ source code.
// ============================================================================
// LockDataLogger_Click
//
// Description: Event handler implementation
//
// Parameters: pSender - The dependency object that raised the click event.
// pArgs - Event specific arguments.
// ============================================================================
HRESULT MainPage::LockDataLogger_Click (IXRDependencyObject* pSender, XRMouseButtonEventArgs* pArgs)
{
HRESULT hr = E_NOTIMPL;
if ((NULL == pSender) || (NULL == pArgs))
{
hr = E_INVALIDARG;
}
//m_pDeviceSettings_Lang->m_pYear->Focus(false);
if(m_pDeviceSettings_Lang)
{
m_pDeviceSettings_Lang->m_pYear->SetIsDropDownOpen(false);
}
m_pLoginScreen->SetVisibility(XRVisibility_Visible);
m_pLogin_Password->SetPassword(L"");
m_pHome_LoginOptions->SetVisibility(XRVisibility_Collapsed);
return hr;
}
So this is an event handler implementation for when you clock the "Lock" button on the home screen of my device. All you need to do is name your different pages/menus accordingly and based on event handler implementations, using points, set/change the visibility of the different pages. Very straightforward and hope the example code provides some insight.

Related

Extend Windows explorer with BHO

I am trying to extend whindows explorer (NOT IE) with a customized panel in C++, which should look like this:
and here's a similar question I found (in C#) :
Similar question
The question is of C# and already got an answer.
But I myself find the answer is a bit too brief for me to follow, here's what I got:
I should implement a BHO object
the BHO object should implemet IObjectWithSite and IDockingWindow
In SetSite method, call QueryInterface to get the pointer of service provider, then call QueryService to get the pointer of a Docking window frame, then finally call AddToolBar to add my customized window. and here's where I got lost
and my questions are:
at what time should I create my customized window? during the initialization of the object?
I think I should get a parent window's handle (in my case I think it should be the windows explorer's handle) before I can create my own window which will be a child of it, where can I get this handle? with the pointer of docking window frame ?
How should I register my dll? I read some sample codes of preview handlers, we have to register the dll properly before it can be invoked by the system right?
I've tried to reproduce what the similar question said for days, but no luck by now.
I'm really new to BHO and all such stuff, kindly please help me out of this, thanks.
For such Explorer extension I create 2 object. First implements BHO (IDispatch and IObjectWithSite). Second implements IObjectWithSite, IOleWindow, IDockingWindow, IInputObject and IOleCommandTarget.
1) The logic of showing of your window depends on what you want to realize.
2) Parent window you can get inside Second.SetSite:
Site.QueryInterface(IDockingWindowSite, FDockingWindowSite);
FDockingWindowSite.GetWindow(FParent);
3) Just register your BHO as standard BHO.
It took a LONG time for me to create and debug such extension. If you are not expert in this sphere think again - do you really need this functionality. But if you really decided you need then try to create and register simple BHO first. And only when BHO works correctly add IDockingWindow implementation.

How can I change the language in AfxMessageBox?

I have an MFC app that uses AfxMessageBox to display message boxes. The app itself lets an end-user to change the user interface language. On the inside it does so by loading resources using LCIDs (or FindResourceEx API.) My issue is that I can't seem to make AfxMessageBox to take LCID to change the language for OK, Cancel buttons, etc. This also affects File and Folder Open dialog windows.
Any ideas how to do this?
PS. This approach must work under Windows XP and up.
According to this SO article, there are no standard functions for this, there's a link to a CodeProject article "Localizing System MessageBox" with source code for a DLL (it's in c# but seems simple enough to be rewritten in C++) which uses Windows Hook so that you can supply your own text for the MessageBox buttons; there's even a suggestion for sizing buttons to the text in the discussion part of the same article.

How to use the Document/View architecture in MFC

I'm still working on a Data Acquisition program in MFC and am getting stuck working with the Document/View architecture. Basically, I want my application to have a couple windows. One is used to show a video that's recorded from a high speed camera, another has a plot displaying data from the DAQ system, and maybe another has controls for configuring the camera and DAQ, etc.
So, really I have a lot of modeless windows each showing a portion of the data, usually from a different source. Now, going through and using the App Wizard I get confused with the Doc/View stuff, and even though I can turn it off, it isn't technically off. Now that aside, I've tried opening modeless Dialogs and FormViews all to no success. Mostly I just can't figure out how to open the new View, the documentation isn't really helpful. I've been able to open a Modal plotting dialog from a Ribbon Button command and I mark that as a success, but not exactly what I need.
So, does anyone have helpful insight on fitting my application to the Doc/View architecture or opening a modeless dialog or FormView from within another application. I should say I'm using Microsoft Visual Studio 2010 and I'm using MFC and C++.
EDIT:
So, I've gone with MDI and will have one document that handles all the data to be shown. What I am stuck on now is how to create the multiple windows I want. I sublcassed CFormView to be the graph View of the document, and I am trying to create that window when I click a menu button. I was able to do it with a modal Dialog, like this:
void CDAQUniversalApp::OnScopebtn()
{
// TODO: Add your command handler code here
CScopeDlg dlg = new CScopeDlg(); //CScopeDlg is Subclass of CDialog
dlg.DoModal();
}
That worked, but not what I want, so I tried this, and it didn't work at all:
m_pScopeTemplate = new CMultiDocTemplate(
IDD_SCOPEFORMVIEW,
RUNTIME_CLASS(CDAQUniversalDoc),
RUNTIME_CLASS(CMDIChildWnd),
RUNTIME_CLASS(CScopeFormView)); //Subclass of CFormView
if (!m_pScopeTemplate)
return FALSE;
void CDAQUniversalApp::OnScopebtn()
{
// TODO: Add your command handler code here
CMDIChildWnd* pFrame = NULL;
pFrame = DYNAMIC_DOWNCAST(CMDIChildWnd, CWnd::GetActiveWindow());
CMDIChildWnd *pScopeFrame = (CMDIChildWnd*)m_pScopeTemplate->CreateNewFrame(pFrame->GetActiveDocument(), NULL);
if (pScopeFrame == NULL)
return;
m_pScopeTemplate->InitialUpdateFrame(pScopeFrame, pFrame->GetActiveDocument(), TRUE);
}
This just causes an unhandled exception. I really just bruteforced my way to that point finding various largely unhelpful sections of documentation code and modifying it to what I think I need.
Your different windows (for video display, data display and configuration) are actually all views (different view classes) for a single document, which manages the data (assuming the DAQ works on the video data?).
I suggest you pack your application into an MDI app, thus having a main window, with all those different views as subwindows. So you have multiple views for a single document (or even multiple documents in MDI).
MFC can be a pain, if your application does not fit the classical document/view architecture (like Word for example), but I think this would be the best way to fit your application into this framework.

How to practically customize IE context menu?

I need to add one menu item in IE context menu. It is similar with Google customized context menu "Search Google for xxx" when you right click on IE.
I did a research and found that overriding IDocHostUIHandler::ShowContextMenu in a IE BHO can customized IE context menu. The sample project can be found in Popup blocker project published in codeproject. It works well and is easy to implement. However this approach has a problem. The problem is it will conflict with other add-ons' context menu customization per MSDN.
In MSDN Internet Explorer Center forum, there are some discussions about this topic. However there is not a proper implementation posted.
If anybody has experience on this, please share your idea. Thanks!
See Adding Entries to the Standard Context Menu on MSDN.
For some sample code, download and extract the Web Accessories for Internet Explorer 5 (the mechanism still works in IE versions up to and including 8). Look at ie5wa.inf and *.html for examples of various IE context menu extensions.
Note that the abive is achieved without COM, purely via one registry setting and a file containing a blob of script (Javascript, JScript, VBScript etc.) The script (JScript, VBScript) may in turn work with COM objects, should your menu action logic reside in such an object, e.g.
create a HKCU\Software\Microsoft\Internet Explorer\MenuExt\My &Context Menu" registry key (&` precedes the menu accelerator letter, if any)
set the default value for the key to point to a file containing the script code implementing the context menu action(s), possibly interacting with a COM object (must support IDispatch IIRC; also read up on the My Computer Security Zone)
create a binary contexts value (0x02 for images, 0x10 for selections, etc.) which regulates when the new context menu should be displayed
I customized my IE in order to navigate to a selected text. You can read the full story and get detailed source code here.
The hearth of my solution is built around the following javascript code and the Registry key [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MenuExt]:
var parentwin = external.menuArguments;
var doc = parentwin.document;
var sel = doc.selection;
var rng = sel.createRange();
var str = new String(rng.text);
if(0 < str.length)
{
if (str.indexOf("http")!=0)
window.open("http://"+str, "_blank");
else
window.open(str, "_blank");
}

Choosing between a Dialog Based Vs SDI Projects

I am new to MFC well not entirely new but wanted to ask experts on this forum as why one would choose one project over the other. I hope this is not a stupid question as I am relatively new to MFC.
Thanks so much
Chose based on what template your application fits best into:
Single Document Interface (SDI) - if your application needs to work with only 1 document or data object or data set at a time
Example: notepad.exe
Multiple Document Interface (MDI) - if your applicaiton needs to work with multiple documents or data objects or data set at a time
Example: Visual Studio
Dialog Based - for anything else.
Example: Calculator
No matter what you chose, you still have the same functionality available to you in the end and you can cusotmize it in any way. So you aren't limiting yourself to anything you start with.
All variants come with CWinApp which is the base class for which you derive your MFC applications.
With a dialog based application you start with a CDialog as well. With an SDI application you start with CMainFrame, CDocument, and CView as well.
If you select an SDI project you get a whole Model-View-Controller framework included.
You get a document class (inheriting from CDocument) which ideally should hold all of the data, and a view class (inheriting from CView) to do with the display.
You get given a hosting frame with a menu already attached, and there are functions you can override to save and load to file.
If you have a dialog based application, then you get one dialog. That's it. Of course, this dialog can spawn off others, but the application essentially consists of a dialog.
If you're developing a small application that just does one task, a dialog application is appropriate, because you don't need the overhead.
If you are developing an application where the user will be loading, editing and saving data, then the SDI path would be more appropriate.
Having answered your question, I'd politely ask if there was a compelling reason why you were choosing MFC over Windows Forms. I believe that MFC was an excellent technology for its day, but the Visual Studio suite offers more advanced tools (if you're prepared to go down the .NET path).
If a "document" is the right metaphor for your application, use SDI or MDI. (Single of only one document can be open at a time, Multiple if more than one.) When you think about it, the document metaphor really isn't appropriate for most applications.