Hello fellow WT users. I have a problem with enabling the user the ability to choose a save location for some data in my application. I have noticed that WT has an absence of an easy to use save/open file dialog boxes or widgets for the purposes of browsing the hard drive of a machine for a save location or a file to load. I would imagine both of such widgets return the path of said location or file to load, but alas I have not found any. I have also looked at Wt::WFileUpload Class but had a hard time understanding how exactly to use it, and after googling around some examples determined it is probably not what I am looking for.
Why not use windows OpenFileDialog? Well, in this project I have WT overlayed over a full screen application as a UI, if any other windows open the application would minimize(which is bad). Which is why I'm looking to browse the hard drive in just WT.
After thinking about this for a while, I figured why not just write my own file browser? So after a bit of digging I came across the MVC Tree Views. Those look pretty close to Windows Open File Dialog, except that I would need to write my own code for building and displaying the trees, browsing the hard drive with boost, then handling all the saving and loading myself.
Which I am not apposed to, it just seemed reasonable to check with the community before I jump the gun and write a lot of code that I potentially might not need to. It seems odd that WT does not have anything to support hard drive browsing, which brings me here.
Does anyone know anything about a Widget, or a clever combination of Widgets, or another WT method to enable the user to browse the hard drive of the machine in just WT?
Thanks in advance for any help!
The filetreetable example does more or less what you ask.
Related
I have been tasked with the creation of a desktop application within some very rigid constrains. The first version of the application was quite small, only intended for some specific tasks, but it seems like the application was quite liked, so I've been asked to improve it a lot.
The initial app I created was made as a hta with heavy doses of javascript and jquery, using a XML to store information (through MSXML2.3.0), but the increased amount of data makes me think it won't be able to keep up with the requirements, so I wanted to remake the application on a more solid base. Of course, I'd rather keep the interface more or less consistent with what I've already shown, and I'd prefer not having to rewrite all the code.
The restrictions are as follows:
-Desktop application. I cannot develop a web application, as not a single target computer has a solid internet connection.
-No need of installation (copying and pasting the folder should work, and should keep all the data consistent).
-Should be relatively multi plataform. The only information I have about the target machines is that all of them have a windows XP OS or newer, a MS Office 2003 suite or newer, and some kind of PDF reader.
-Should be able to embed and show different file types, such as diferent image formats, pdfs, and office documents. That said, for office documents, as long as I can link to the document and open it by instanciating a common MS Word/Excel/wathever app, it should be good enough, although interoperativity with the suite would be great.
I've been searching through the net, and I've found some interesting options, but I'm not sure about them.
On one side, I think XML won't be able to keep up, although I suppose I could make it work if I distribute the data through several xml files. I've been reading about open source embedded databases, such as SQLite, and it looks like this could work.
On the other side, I feel like the hta basis I'm using isn't going to work that well if the application keeps growing. I've checked lots of alternatives, but all of them give me some problems.
Cappuccino or Chromeless looks like good ideas, but both of them require a certain degree of HTML5, which is something I can't be sure the machine's browser will support enough. Also, NativeHost for Cappuccino seems to work only on Mac OSX. Xul looks interesting, but unusable.
Another option I've found is porting the app to Qt, but I don't know how hard would be porting the app to Qts, and it looks like I can only use the ActiveX needed for the embedding of MS Office applications with a proprietary license. Although that's comparatively less important, but I'm sure in the future I'll want to include those features.
That's how I stand. Do you think keeping the hta + XML architecture (or any variation thereof) could still work? Do any of the alternatives I've mentioned be viable? Do you know any other alternative?
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.
I know this has been asked twice before but both had no proper replies and are dated so in case someone has found something in these days, I'm asking again!.
Any one knows any good tutorial for MSHTML or some open source project which can be read to understand how various operations can be done in MSHTML - MFC?
Thanks
Your question makes it difficult to know exactly what you are trying to do, but the main MFC class that you need to use is CHtmlView. The MSDN has the definitive sources of information about it:
CHtmlView class
Creating a Web
Browser-Style MFC Application
Using MFC to Host a WebBrowser Control
If you find those links a bit terse, then this page contains some slightly friendlier articles:
Advanced CHtmlView Hosting
However, I would also ask whether you are definitely 100% sure that you want to use MFC?
The reason I ask is because I've worked for a number of years on an open-source project that hosts the Microsoft WebBrowser control and we saw significant performance improvements when we stripped out MFC from the project. The MFC abstractions weren't really buying us anything over the COM interfaces that are exposed by the control. Stripping out the MFC also made our code much simpler.
The project is open source, so if you want to see the code for yourself, you can get more information here. It is specifically the LibRender project that hosts the WebBrowser control. If you want to see it running, you should build the SWViewer solution.
The one place I like to visit for MFC is Newcomer's site There are some useful tutorials and demos of various things there. Although its more of a general MFC site, so maybe you can find what you are looking for there.
This project started as a development platform because i wanted to be able to write games for mobile devices, but also being able to run and debug the code on my desktop machine too (ie, the EPOC device emulator was so bad): the platforms it currently supports are:
Window-desktop
WinCE
Symbian
iPhone
The architecture it's quite complete with 16bit 565 video framebuffer, blitters, basic raster ops, software pixel shaders, audio mixer with shaders (dsp fx), basic input, a simple virtual file system... although this thing is at it's first write and so there are places where some refactoring would be needed.
Everything has been abstracted away and the guiding principle are:
mostly clean code, as if it was a book to just be read
object-orientation, without sacrifying performances
mobile centric
The idea was to open source it, but without being able to manage it, i doubt the software itself would benefit from this move.. Nevertheless, i myself have learned a lot from unmaintained projects.
So, thanking you in advance for reading all this... really, what would you do?
Throw it up on an open source website and attach a bunch of good keywords to help search engines find it. If someone's looking for it, they'll find it and be able to use it.
I would say that you should open source it.
If you do have the time, it may be helpful for other programmers who are interested in the project to know the status of the project, and what is next to do on the project. Writing a to do list may be helpful, or writing comments in the code may also help.
If you do not have the time to write up a to do list maybe somebody is willing to take the initiative on the project, find out what needs to be done.
Look at it a different way. The worst that can happen is that your work will go unnoticed, and your efforts will be lost. The best that can happen is that you will be recognized for having the foresight to start such a great project, and open sourcing it.
http://sourceforge.net
This allows you to set up as admin and manage the project.
Of course if somebody does not agree with you they can fork the project and start their own version but that's open source for you.
If you've put time and effort into it, don't let it die a quiet death. Instead share it under the license of your choice on a collaborative site. At the worst, you get nothing in return. At the best, other people like the idea and provide constructive feedback or code. Even better is if you get some time in the future to pick it back up.
Couple of good sites to post it on
codeplex
sorceforge
Definitely, you should open source it, just make the same considerations you made on this question on a place that anybody can see...
Maybe someone will pick it up, or just learn from it
Put it up on github so we can all check it out.