|
|
Hello,
I would like to print to the printer from my developing application, but I don't want to use any of my existing views because they're not printer formatted (I'd like to print a report style.). I have read about printing but it appears that all the printing support functions are tied to my existing CView (also, the class wizard adds them to my CView).
How should I print to the printer using a unique view so that the user never sees this new view on the screen?
thanks! JennyP
|
|
|
|
|
Do you need print preview ?
If you do, the situation gets more complicated, as all previewing support for MFC is tightly linked to the view architecture.
But if you don't, then you can simply enumerate the available printers, create a compatible DC with any one of them, then paint your printing onto the DC and send it over to the printer. The printer driver will worry about the rest. DCs created for printers are automatically matched to the printer's color, dimension and other settings, making it pretty straightforward procedure to print with them.
I suggest dwelving into this[^] and this[^] articles in the MSDN Library. First one handles the usage of a custom view for print preview/printing and the next one shows a simple code example to directly use the printer DC.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hi all,
Is there anyway to feeds data entered in an MFC application to a nicely formatted form in MS Word? In another word, can I take data in the edit boxes and fill in the corresponding fields in MS Word?
Thank you for your help!
|
|
|
|
|
You can do this by using the Word automation com objects.
onwards and upwards...
|
|
|
|
|
The contact view in Outlook 2003 has a grid control that is exactly what we want. Does anyone know of anyone who makes and/or sells one JUST like it (or very close)?
Please don't post references to all the grid controls here on Code Project; we've already tried several and find them extremely ugly with poor usability.
(And why can't Microsoft just publish the Outlook one and/or put it in the common control?)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Microsoft hasn't published any of the useful Outlook controls yet mostly because there are commercial versions available. Releasing them as freeware might hamper the sale of the currently existing ones.
The two most promising toolsets and Dundas Software's ToolBox and CodeJock's Extreme Toolkit Pro. Both have their advantages and disadvantages which have been discussed on other forums quite often. I also believe that both offer a set of Outlook's controls, perhaps even the grid control of the 2003. See their respective sites for more information.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Antti Keskinen wrote:
Releasing them as freeware might hamper the sale of the currently existing ones
They don't have to release them as freeware. I'd be willing to pay MS thousands for their SUPERGRID control (it would save tens of thousands in engineering and testing.)
Dundas has a grid control, but it's not really what we need. It's also way too big. CodeJock has a nice list control box, but still not what we need.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
The Dundas Ultimate Grid can be made to look very close to that using a custom cell type. I suggest you give it a try. If you are not up to the job of creating a custom cell type we can do that as well. It looks like a 2 - 3 hour job.
Ivor S. Sargoytchev
Dundas Software
|
|
|
|
|
Hi guys, I have a question about function pointer passsing. The following
code is the beginnings of a Win32 app.
main.cpp<br />
<br />
#include "windows.h"<br />
#include "classOne.h"<br />
<br />
<br />
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)<br />
{<br />
return 0;<br />
}<br />
<br />
<br />
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,<br />
LPSTR lpCmdLine, int nCmdShow)<br />
{<br />
Nothing n(WndProc);<br />
<br />
return 0;<br />
}
As you can see, all I'm trying to do is pass the WndProc function as
a parameter to the constructor of a class called Nothing.
Nothing.h<br />
<br />
#include "windows.h"<br />
<br />
class Nothing<br />
{<br />
public:<br />
Nothing(WNDPROC wndProc);<br />
};
Nothing.cpp<br />
<br />
#include "classOne.h"<br />
Nothing::Nothing(WNDPROC wndProc)<br />
{<br />
int kk = 0;<br />
}
Well my question is, why is it that when I step into the constructor of
the "Nothing" class, wndProc appears to have a different address than
the one I passed in? For the life of me I can't see why this is the case as
WndProc is typedef'd as LRESULT (*WNDPROC)(HWND, UINT, WPARAM, LPARAM)
I'm sure that if I go any further, I'm likely to get an error for example,
when I use that address to initialize and register a window class.
Any hints??
Woke up this morning...and got myself a blog
|
|
|
|
|
What you are passing here is a pointer to a function. The name of a function is always it's address, like using the address-of operator automatically. This address, of course, refers to the starting point of the function in memory.
However, in this case, the constructor seems to create a copy of the function, and move it into a seperate place in memory. I do not know why it does this, but calling the function does work properly. Here is the code fragment with which I tested it.
#include <iostream>
using namespace std;<DIV>
typedef void (*ptrFunc1)(int, int, double, double);<DIV>
void MyFunction( int a, int b, double c, double d )
{
cout << "Inserted: " << a << " " << b << " " << c << " " << d << "\n\n";
}<DIV>
class Nothing
{
public:
Nothing(ptrFunc1 func1);
};<DIV>
Nothing::Nothing(ptrFunc1 func1)
{
int a = 10;
int b = 20;
double c = 30;
double d = 40;<DIV>
func1(a, b, c, d);
}<DIV>
int main(void)
{
Nothing MyNothing(MyFunction);
}Although whilst in debugging, the addresses of MyFunction and func1 are different, and even (*func1) points to a different place than MyFunction, the code calls MyFunction properly through the func1 function pointer, and the text gets printed out correctly.
I see no reason why your implementation would not work properly as well. The reasons of why the memory locations are different is unknown to me, it would require some more work to determine it. I even tested it by creating two objects of class Nothing. In that case, the func1 pointed to the same location in both cases.
So, although I don't understand why it happens, the code works, so you shouldn't have anything to worry on that part 
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
i have two projects ,, one MFC dialoged base and other is WIN32
i want to place them in 1 workspace..
and also want to communicate between these 2 projects classess.
for example .. in MFC i have created a socket by CSocket class ,, now i want to this socket in my WIN32 application ,, how can i do it .
Plz help me its urgent
thanx
|
|
|
|
|
Having two projects in a single workspace is easy.
Just open the workspace you want to have both projects in, then go right-click on the workspace name and add an existing item/project to workspace. Remember to take the tick off from 'Dependency of' radio box if it is checked.
As the two projects are seperate applications and thus run on seperate processes, the only feasible solution is to use a named pipe between them. Have the MFC application create a named pipe, and write it's data in there. Then signal the Win32 application to open the pipe and read data from there. Remember that in this case, you cannot pass for example a pointer to the CSocket class through the pipe to the other application, as this pointer is no longer valid when it leaves the context: using it will cause a protected-mode memory failure, or in Windows 95/98, the notorius Blue Screen of Death.
If you want to share viable data, such as pointers to classes or data, between the two applications, then you must run them under the same process space, on seperate threads. The MFC program can create a new thread, and hit the Win32 application running there. Then it is just a matter of cross-thread messaging to pass stuff between them. Naturally, a named pipe is a useful solution in this case as well.
Even simpler solution to use the Win32 application, you can call the LoadLibrary function, get the address of the starting point function (WinMain) from it, then call it manually. This will load the application into the MFC-program's process space and execute it's WinMain function, which simulates running the program. In this case, of course, the WinMain function must be exported from the executable and a definition file is required.
There are a few articles available here on CodeProject about cross-thread and inter-process communication. See this area[^] for some examples.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
To have two projects in one workspace, simply "add existing project" from context menu on workspace (as I remember).
If you want to use the other project, you can import/export some data. In case of socket it will be more difficult, cause you will not be able to debug two projects from one workspace in one vc at once
|
|
|
|
|
I have a sound data in array of 1MB ,
how can i send it through CSocket class ...
Is there any type ast needed.. if yes then how.
will it loose data or not..
thanx
|
|
|
|
|
Check out this link for a reference to the API.
To answer your question, if you create the socket with the SOCK_STREAM flag, then the TCP will be used and you will not lose any data since TCP is a reliable transport. However, if you want a potential speed-up in send times (at the risk of losing data), create the socket with the SOCK_DGRAM flag to create a UDP connection.
The Send function takes data in the form of a void* (see above link for further reference).
--Dean
|
|
|
|
|
I have a program that has a list view on a dialog. I have a separate thread from a DLL go out and get some data (from Outlook Express in this case). The data ends up begin returned OK, but wehen I try to add the data to the list control, the data keeps getting put in the first entry. I am using InsertItem(-1, NULL) to insert the data into the list control. The funny thing is that this is working in other modes, just not this one. Anyone have any ideas?
By the way, the app consists of a main EXE, which calls an MFC DLL (which holds the UI). The UI DLL in turn uses an extension DLL to save and load data. The UI DLL also calls an MFC DLL to handle the import of the data (no UI).
Any help would be greatly apprecaited.
[EDIT]
By the way, this only happens on onc test system with Windows 98. Other WIndows 98 systems seem to work fine.
[/EDIT]
Regards,
Brigg Thorp
Software Engineer
Timex Corporation
|
|
|
|
|
Yeah, I remember that problem. It seems to be special Win98 index behaviour. I circumvented it by simply using:
int x = 0;
while(<cond>)
{
InsertItem(x, "");
x++;
}
BTW I'm not sure it's safe to use NULL as text either
Nick
|
|
|
|
|
Is there any way to force the title of a MDI app to display what you want.. Example lets say I want my MDI title to all ways read "Rob".
When I open new documents or switch between docs I dont want the title to say "My App - [Rob]" I only want to see Rob.
I kind of remember seeing a flag you can set in PreCreateClient that disables this auto-naming feature. But I cant figure it out for the life of me.. 
Any Ideas?
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Just incase anyone else forgets the darn flag its FWS_ADDTOTITLE
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Here's the deal, I have a test class that I am working on and everything seems to be in order, yet I am struck with a link error for every time I use this class (I am using this class from my main() function in main.cpp).
-I have added both the header and source file for the class into my VC++.NET 2003 project.
-Within my main.cpp, is my main() function. At the top of this file, I have the header file to my class included.
-I have my class header file included at the top of the class's implementation/source file.
-The strange thing is when I ALSO include the implementation (.cpp) file at the top of the main.cpp file, it compiles and links with no problems, but I shouldn't have to be including both files.
What am I doing wrong? Or has my VC++.NET 2003 just gone crazy? 
Any points into the right direction would be greatly appreciated.
Happy Programming!
WWW::CodeProject::BNEACETP
|
|
|
|
|
It's tough to figure out this problem without details about your header/implementation and what the link error is.
Is your class a template? If so, then the implementation must be defined in the header.
- Mike
|
|
|
|
|
Michael Imamura wrote:
Is your class a template?
Yes it is.
Thanks for the info about template class inclusions. I will simply add the implementation code to the header file then. Once again, thanks. 
Happy Programming!
WWW::CodeProject::BNEACETP
|
|
|
|
|
Hi,
I have a weird linking error happening in my C++ DLL project. In VS.Net 2003, when I compile my dll in release mode, I get the normal "linking... Creating library c:\some_path\blah.lib", but if I do the same in debug, I get "linking..." but the .lib doesn't get created/updated. Other than that, it seems to compile file. No errors get generated.
I've checked the settings between both modes, and I can't see anything different between them.
If I do a "rebuild all" it does update the .lib, but not if I just modify a file and compile the project. I don't want to "rebuild all" everytime I want to test a change. Any ideas?
Thanks!
DJCC
|
|
|
|
|
I've noticed the same thing too. This is just a guess, but I think it's probably fine if the .lib file isn't updated. Basically the .lib file provides the interface for the DLL that you will link against in some other program. So, if you just update the implementation (rather than the function signatures) there is no reason to update the lib file, because the interface to the DLL remains the same.
Again, I'm not 100% sure about that so someone correct me if I'm wrong, but I think you'll be fine linking against the .lib file even if it's not updated.
--Dean
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
