We may start converting an old VS2003 MFC project to use the fancy new features provided by the MFC Feature Pack and VS2008. Several of the new UI controls would be very nice except for one thing - they automatically save their information to the registry. I don't have a problem with the registry, but for the multiple environments the users use out program from, it's much easier to save user data to the database.
So, I'm hoping that there is one main "access the registry" function that could be overloaded to point the database. But brief investigation hasn't turned up anything. Has anyone else had any success doing something similar?
It seems like it should be possible to do what you're suggesting, according to the information on this page in MSDN. I haven't tried this myself, so I don't know how difficult it will be in practice.
According to the documentation, you should create a class that inherits CSettingsStore to read and write the settings, and call CSettingsStoreSP::SetRuntimeClass so that the framework uses your class instead of the default.
The MFC feature pack uses code supplied by BCGSoft and they added this feature (so you can save state to an XML file, database, etc.) way back in 2001. I don't have the feature pack on this PC but try looking for a class called something like CMFCRegistrySP.
I will check myself tomorrow.
Does the StateCollection sample do this?
http://msdn.microsoft.com/en-us/library/bb983406.aspx
Related
I am building webparts and self hosted apps for sharepoint 2013, I want to consume the Query String filters that the user sets up, the process should be as simple as specified here on this microsft site.
Unfortunately I dont get the option to send values to 'my web part' but I do for other stock webparts that come with sharepoint. Which leads me to believe I need to implement IFilter or equivelent in my webpart, I have found information into IFilterConsumer interface and IFilterProvider interface on msdn which seems to be exactly what I need, however the documentation has one snag:
NOTE: This API is now obsolete.
So My question is, what is Microsofts new intended way of doing this with Sharepoint 2013.
Ultimately I need to read query variables in the HostWeb request inside my AppWeb code.
Edit: Apparently IWebPartParameters is the new interface for this.... trying to implement now.
I have also tried whats suggested here:
Passing parameters through sharepoint sitepage to web part Still not working, at the moment I have implemented IWebPartParameters, IWebPart, IWebPartRow and none of my functions that implement these interfaces are being called. I must be missing something in the manifest or features file maybe?
Thanks in advance
Crash
Ok the answer to this question is simple, firstly you can only do this in a dev environment with sharepoint installed, as you need access to the sharepoint.dll.
Then this thread answers the question http://www.manning-sandbox.com/thread.jspa?threadID=19791, with the following code solution which is here http://www.markitup.com/BookCodeSamples/TestingWebPartConnections.zip
Since time immemorial I've been trying to avoid printing from my Windows-based applications due to the lack of native support for it. Whenever absolutely necessary I was resorting to dynamically making a simple HTML layout and then opening it in a web browser with a short Java Script in it to pop up a printing dialog for a user. Now I need to find something more substantial.
Let me explain. I have a project that deals with medical charts and it has to be able to print into those charts (at specific locations) as well as print on to a Letter/A4 size page in general. It also has to provide a preview of what is being printed in a paged-view environment.
In light of that I was wondering what is available from MFC/C++ environment (not C#) in regarding to printing?
PS. I was thinking to look into the RTF format but that seems like quite a daunting task, so I was also wondering, is there any libraries/already written code that can allow to compose/view/print RTFs? If not, what else is out there that can provide printing support like I explained above?
"lack of native support"? It's been covered by Petzold since forever, and it's integrated straight into GDI. Compared to UNIX, it's a complete breeze. And MFC makes it even easier.
Anyway, here's how you do print preview with MFC, and here's how you subsequently print. Lots of links from there, and it's all straightforward. Printers are just another Device Context on which you can draw.
I always found it very convenient to generate PDF files from my MFC/C++ application, There are many libraries out there which enable easy creation of PDF files, preview functionality and so on (also open source). I'm using this (also handles RTF):
PDF Library
There is no support like you call a framework method with some parameters and the framework prints a document or the content of a window for you. You need to manually draw everything on the printing device context. So as already said, you might find it more convenient to use a PDF generator, but of course that depends on your application requirements.
Please try www.oxetta.com , it's a free report builder solution that easily integrates into a C/C++ application.
This is my first substantial MFC application.
My out-of-the-wizard MFC app wants to open a blank, new file of the type I specified for my app, when it starts, but that's not meaningful for my application. I want my app to open some connections to some remote sites and get data from them.
Where should I consider interrupting or overriding MFC's default behavior? I could subclass CWinApp::ProcessShellCommand(). I could modify the CCommandLineInfo object it works on. I could excise the whole command line processing and just call my go-get-the-data functions. I probably should just altogether excise the whole document-as-a-file related processing. I'm not opening or saving any files, except debug files or logs that are outside of the UI's concern. The only saving or collecting of local information is via a database, to which and from which I handle the serialization myself, so no CArchive, either.
I've got all this code but it's hanging in front of me disjointed and disintegrated. I'm too new to this and there's too many alternatives. Some simple guidance for a simple beginner is what I'm asking for.
So, if you'll say, sure, lop off the document-as-file handling, tell me, please, where I need to go to do that bit of surgery, I can see it's not just one object that'd be affected. And so forth. Thanks.
You might consider generating a new application, but when you do, tell it that you want a database application without file handling. Even if you don't use its database capability, it'll produce an application whose basic layout is set up roughly for what you're trying to do, so you'll basically just substitute your database interface for what it provides, but won't get involved with trying to rip out file handling and such that's apparently irrelevant for your program.
I found an answer with respect to modifying default file opening. While I made the database app Coffin suggested, I saw the phrase "storing database objects in views" and I rather aimlessly searched MSDN with that. If I was going to try the database app approach and do my own serialization, I had to learn about this.
I thus found an MSDN page concerning handling the file menu in database apps, which discusses how to alter and even disable the OnFileOpen command. It's applicable to OnFile New and it is the approach I was hoping for.
Disclaimer: I'm not a c++ developer, I can only do basic things. (I understand pointers, just my knowledge is so rusty, I haven't touch c/c++ for about 20 years :) )
The setup: I have an Outlook addin, written in C#/.Net 1.1. It uses a c++ shim to load.
Usually, this works pretty well, and I use in my c# code nlog for logging purposes. But sometimes, the addin fails to load, i.t. it does not hit the managed code at all for me to be able to investigate the problem from the log files.
So, I need to hook some basic logging into the c++ shim - just writing in a file. I need to make it as simple as possible for our users to enable. Actually I would prefer not to ship it by default.
I was thinking about something, which will check if a specific dll is present (the logging dll), and if so, to use it. Otherwise, it will just not log anything. That way, when I have a user with such a problems, I can send him only the logging dll, the user will save it in the runtime directory, and I'll have the file.
I guess this have to be done with some form a factory solution, which returns either a dummy logger, or if the dll is found, a real one.
Another option would be to make some simple logger, and rebuild the shim with or w/o using it, based on directives. This is not the desirable approach, because the shim needs to be signed, and I have to instruct the user to make a backup copy of the "real" one, then restore when done, etc., instead of just saving and deleting a dll.
I'd appreciate any good suggestion how to approach it, together with links or sample code how to go after this.
Cheers
The loading of the logging dll's seams like a complicated way of handling the configuration issue. Why not use the registry. If you use conditional loading on dlls you will be using LoadLibrary and GetProceAddress and as you said your not really a c++ coder so why introduce the complexity. Also there have to be n+1 c++ logging libraries available have you looked into any of those.
Some I found after a Google search
log4cpp
rlog
Why not have a registry key for that? The user opens regedit, adds a key and your library starts logging. The logging code will be in place all the time, just not invoked when the key is absent or set to "no logging".
I have a Doc-View architecture based project completely ready. But now i want to convert it in container based application to provide OLE support to existing project.
if anyone know how to convert, please reply as soon as possible. i just need a way without copy paste of existing code to new container based application- i tried - not worked even after settings change.
There is a good worked example of this here. Basically all your CDocument derived classes must be now be derived from COLEDocument, and you need some extra code in your WinApp.InitInstance.
If you post the code that you tried, you may get a more detailed response as to what is going wrong.