What are "OLE Overridables" in MFC (as opposed to just Overridables)? What does OLE mean?
OLE stands for "Object Linking and Embedding". It is an old term for a technology invented by Microsoft that allows embedding controls in control containers and sending it data of various kinds (example here would be an Excel spreadsheet embedded in a Word document.)
Specifically relating to MFC, it sounds like you are referring to the "Overridables" section of an MFC .h file. They are basically the OO way to handle events such as OnDraw(), OnPaint(), etc.
(See http://msdn.microsoft.com/en-us/library/8bst0130.aspx for more info).
Does this help?
Related
Are the any alternatives how to display PDF/HTML file in the MFC based application without using ActiveX elements like CHtmlView?
Thanks in advance.
The alternative would be WebView2. It uses the Microsoft Edge (Chromium) browser engine, unlike CHtmlView that's based on IE.
If the reason you are looking for an alternative is, that you need a more up-to-date browser implementation, then WebView2 delivers. If, on the other hand, you are looking for an alternative, that's easier to use, then not a whole lot changes. Either one expects very intimate familiarity with COM and C++.
I'm trying to learn the MFC to code for Windows and I've come across things like the ID_FILE_EDIT macros that are defined as being unicode values I think. I understand, I think, that the macros specify the item in the menu pulldowns. Question is, how do I define my own and where do I put them. I'm trying to get custom menus and custom menu buttons to stem from the MFC. Like I want under file 'new, open existing doc and stuff like that'. I've got VS2013 pro and all the headers I could ever want. Second question is where do I start with the MFC. Should I start by practicing making windows then pulldowns and then... something else? I know where the documentation is at and I understand where the class references are. Really just confused on using it to make my own stuff.
ID_FILE_EDIT (and other defines, like ID_FILE_NEW, ID_FILE_OPEN, etc.) are macros to specify a name for an unique resource identifier that is used to identify a menu command and/or toolbar item. They are typically defined in a header file named resource.h.
Microsoft has released a numbering and naming convention as a Technical Note (TN), because the names and values represented by these macros must follow a certain pattern: http://msdn.microsoft.com/en-us/library/t2zechd4.aspx
Under normal circumstances you can use Visual-Studio's built-in resource editor to create dialogues, menus, buttons, and all the other UI stuff. These editors also assign automatically unique ID's for any resource and generate the macros.
Your second question can not be answered easily. MFC applications are a wide field, ranging from simple, dialogue-based programs to sophisticated Model-View-Controller-based applications. If you just want to play around with MFC to familiarize yourself with the basic concepts of this framework, I recommend to start with a dialogue-based app.
Regards,
Stephan
In VC++ 6.0, Insert menu - Resource - Menu. Is how you add/edit a menu.
Where is the formatting bar gone on answers.
To learn MFC basics, manually build up the Scribble example application (http://msdn.microsoft.com/en-us/library/92y4h944%28v=vs.90%29.aspx) with which whole generations of MFC programmers made their first contacts with MFC. Don't just read it, start with an empty application and gradually add the stuff as in the tutorials. It'll show you a lot. If you don't know the win32 api yet though, you may want to start with reading the Petzold from front to back. Good luck, remember that these are libaries and API's from a time when it wasn't considered unreasonable to spend 3 months full time to learn something.
I want to create a DeskBand to display some information on my Windows task bar, but I am struggling with implementing the functionality I need in C++. It's been about 10-15 years since I touched C++. I've been working entirely in .NET for the past 7 years.
Before you say it - I know that DeskBands are deprecated. But the suggested replacement UI element - thumbnail toolbars - don't meet my needs. I need a UI element that is constantly visible to the user no matter which application they switch to, and also that provides enough room to display a line of text - I could get by with room for 30 characters or so.
I've been able to get the DeskBand from the Windows SDK sample to compile and run, but now I need to implement some real functionality - specifically...
Locating the AppData\Local folder (SHGetKnownFolderPath(FOLDERID_LocalAppData...)
Watching an XML file for modifications. I need to parse and repaint whenever the file changes.
Parsing the XML file (I found pugixml)
Displaying some data from the XML file in my DeskBand
Setting a timer to repaint the DeskBand once per minute
... and I am realizing how little I know about C++, and how much I've come to depend on .NET's Base Class Library. This task would be super easy for me if I was writing it in C#. But I've learned elsewhere that you shouldn't write shell extensions in .NET.
What are my options? Is there an easier language to accomplish this in - maybe Python? Or do I have to just bite the bullet and do this in C++? If so, any advice for a .NET developer trying to implement a WinAPI shell extension in C++?
Thank you in advance.
Shell Extensions are COM objects, and C++ is generally the best language to use when developing COM objects because COM was designed primarily for C++, but it is not the only language possible. COM has a standardized architecture, so you can use any language outside of .NET that supports COM object development (Delphi, VB, etc) to develop Shell Extensions (similar to how the Win32 API is primarily designed for C, but any C-compatible language can access it).
What solutions are there? I know only solutions for replacing Bookmarks in Word (.doc) files with Apache POI?
Are there also possibilities to change images, layouts, text-styles in .doc and .ppt documents?
I think about replacement of areas in Word and PowerPoint documents for bulk processing.
Platform: MS-Office 2003
What are your platform limitations?
Obviously Apache POI will get you at least part of the way there.
Microsoft's own COM API's are fairly powerful and are documented here. I would recommend using them if a) you are not running in a server (many users, multithreaded) environment; b) you can have a proper version of powerpoint installed on the production machine; and c) you can code against a COM object model.
It's a bit pricey, but Aspose.Slides is a very powerful library for manipulating PowerPoint files
If you include using other Office suits as an option, here's a list of possible solutions:
Apache POI-HSLF
PowerPoint 2007 APIs
OpenOffice.org UNO
Using POI you can't edit .pptx file format, but you don't depend on the apps installed on the system. Other two options, on the contrary, make use of other apps, but they are definitely better for dealing with presentations. OpenOffice has better compability with older formats, by the way. Also if you use UNO, you'll have a great choice of languages, UNO exists for Java, C++, Python and other languages.
My experience is not directly with Power Point, but I've actually rolled my own WordML (XML) generator. It a) removed all dependencies on Word, b) was very fast c) and let me build up documents from scratch.
But it was a lot of work to create. And I was only creating a write only implementation.
I'm not as familiar with Power Point, so this is conjecture, but you may be able to roll your own by reading XML (Power Point 2003??) and/or cracking the Office Open XML file (zipped XML), then using XPath to manipulate the data, and then saving everything back to disk.
This won't work on older OLE Compound Document based Power Point files though.
I've done something like that before: programmatically accessed and manipulated PowerPoint presentations. Back when I did it, it was all in C++ using COM, but similar principles apply to C#/VB .NET apps, since they do COM interop very easily.
What you're looking for is called the Office Document Model. Basically, Office applications expose their documents programmatically, as trees of objects that define their contents. These objects are accessible via an API, and you can manipulate them, add new ones, and do whatever other processing you want. It's exceedingly powerful; you can use it to manipulate pretty much all aspects of a document. But you'll need an installation of Office and Visual Studio to be able to use it.
Some links:
Intro: http://msdn.microsoft.com/en-us/library/d58327k6.aspx
Hope this helps!
Apparently new users can only include one link per posting. How lame! :)
Here's the other link I meant to include:
Example of manipulating PowerPoint documents programmatically: http://msdn.microsoft.com/en-us/library/cc668192.aspx
I'm looking for a library that will allow me to programatically modify Excel files to add data to certain cells. My current idea is to use named ranges to determine where to insert the new data (essentially a range of 1x1), then update the named ranges to point at the data. The existing application this is going to integrate with is written entirely in C++, so I'm ideally looking for a C++ solution (hence why this thread is of limited usefulness). If all else fails, I'll go with a .NET solution if there is some way of linking it against our C++ app.
An ideal solution would be open source, but none of the ones I've seen so far (MyXls and XLSSTREAM) seem up to the challenge. I like the looks of Aspose.Cells, but it's for .NET or Java, not C++ (and costs money). I need to support all Excel formats from 97 through the present, including the XLSX and XLSB formats. Ideally, it would also support formats such as OpenOffice, and (for output) PDF and HTML.
Some use-cases I need to support:
reading and modifying any cell in the spreadsheet, including formulas
creating, reading, modifying named ranges (the ranges themselves, not just the cells)
copying formatting from a cell to a bunch of others (including conditional formatting) -- we'll use one cell as a template for all the others we fill in with data.
Any help you can give me finding an appropriate library would be great. I'd also like to hear some testimonials about the various suggestions (including the ones in my post) so I can make more informed decisions -- what's easy to use, bug-free, cheap, etc?
The safest suggestion is to just use OLE. It uses the COM, which does not require .NET at all.
http://en.wikipedia.org/wiki/OLE_Automation <--about halfway down is a C++ example.
You may have to wrap a few functionalities into functions for usability, but it's really not ugly to work with.
EDIT: Just be aware that you need a copy of Excel for it to work. Also, there's some first-party .h files that you can find specific to excel. (it's all explained in the Wikipedia article)
I don't know if this is an option for you, but the new office 2007 formats are in zipped XML format, which makes it very doable to do your own modifications. See here for the specifications.
SpreadsheetGear for .NET will handle your requirements and has an API which is very similar to Excel.
When you insert cells, your defined names (and any other formulas / charts / etc...) will automatically be fixed up to reference the new range (just as they would in Excel). So you would not need to update your defined names (although there is complete support for creating and updating defined names if that is what you want to do).
SpreadsheetGear is a .NET component, but you can build your own wrapper which is callable from C++.
You can see what our customers say and download the free, fully functional evalution here.
Have you already tried using the Excel COM interfaces? Obviously Excel needs to be install on the machine, and it's a pain to deal with...
I would argue that a .net solution with COM interop for linking into your C++ application is the best solution. In more than ten years of working with them, I've never seen a COM automation of Excel that didn't leak memory somewhere.
If you need to automate Excel, I recommend Visual Studio Tools for Office. If you don't need to automate, only modify files and those files can be in Office 2007 format, you're better off finding a library that manipulates the files directly instead of opening Excel to do it.
I ended up using Aspose.Cells as I mentioned in my original post, since it seemed like the easiest path. I'm very happy with the way it turned out, and their support is very good. I had to create a wrapper around it in C# that exported a COM interface to my C++ application.