|
Is this a C/C++/MFC problem or a Windows problem with the printer configuration? Can you print from other applications or print the test page from Windows?
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
That is the problem of my service. I can print well from other programs. Follow this link. I think I have to log on under a user to print, I tried but failed!
|
|
|
|
|
The installed printer is a user profile property. If your service is running under SYSTEM account (see service property login), there is no printer available. You can verify this by running REGEDIT.EXE with the tool SrvAny under SYSTEM account. There is no key HKEY_CURRENT_USER\Printers for the user SYSTEM. It's the same with network drives.
Two solutions:
1. Configure your service to run under any local administrator account. So you can manually login with this account and config the printer before using it.
2. Run your service under SYSTEM account, open the explorer process and use this handle to call ImpersonateLoggedOnUser(), do printing and finally call RevertToSelf (some examples are available in MSDN). In this way the current logged on users printer (and all other settings) will be used.
Under Windows7/Vista/W2k8 interactive services are no more supported. That means you can not show any window or message box at current users desktop from within your service.
|
|
|
|
|
Thanks, I can print from my service now. But there's still a problem.
After calling ImpersonateLoggedOnUser(), I call PrintDlg() to display Print Dialog Box. And I can only print if hwndOwner of PRINTDLG structure is set to NULL. If hwndOwner is set to the Handle of parent window, there's no printer to select in the Print Dialog Box and this dialog box is the dialog box of the function PrintDlgEx(). Quite weird!
|
|
|
|
|
I assume with 'parent window' you suppose the window created by your service, that belongs to the SYSTEM context/process and may annul the previous impersonation.
Try FindWindow("Progman", "Program Manager") as owner, that's an unique valid window of logged on users desktop.
|
|
|
|
|
I am drwaing images on a view So I develped a owner draw control to darw images.
I also need to draw blue order around on mouse hover So I am also drwing. But I am facing some flickering issue How can I reduce it?
|
|
|
|
|
By making your paint code as swift as possible: don't create objects, don't paint more than necessary, etc. Show your code if you need detailed help.
Alternatively, for rubber-banding kind of stuff, have a look at ControlPaint.DrawReversibleFrame(). Warning: it also paints outside the intended Control!
|
|
|
|
|
You can try:
1. use memory dc
2. draw what is necessary
|
|
|
|
|
You might also try handling WM_ERASEBKGND. Do nothing in the handler and return a non-zero value. This will prevent the view window being flood-filled with the window class brush color just before each call to WM_PAINT.
The other key is using some double-buffering scheme. Draw your content on an off-screen bitmap and then blit that to your view, rather than drawing in the view itself.
L u n a t i c F r i n g e
|
|
|
|
|
When is the flickering occuring?
Steve
|
|
|
|
|
Flicker occurs when there are intermediate pixels on the screen. Example: draw a blue,filled rectangle, then draw a non-rectangle bitmap over that. The blue pixels 'under' the bitmap cause the effect. There are 2 solutions: 1) avoid the drawing of unneeded pixels by making your algorithm better (and faster) or using regions (see winapi documentation), 2) draw everything in a buffer (memory DC) and transfer that to the screen. This is called 'double buffering'.
The first solution is most of the times too difficult to implement, so solution 2 is widely used, although it is actually slower.
|
|
|
|
|
Hello all
Good day . Though this question is not relevant to MFC or Win32 but to do with VB generic behavior =>
I have a outlook plugin ( COM plugin ) developed in VB 6.0 . We have an external application which uses the outlook addin to get the contact details from outlook. The problem is here =>
We create a new application object and free it as below =>
Set gApp = New Outlook.Application
....
Set gApp = Nothing
After this code is executed when we click on outlook application it says "Operation failed" . It looks like the outlook application object is not well freed by the statement Set gApp = Nothing . But I checked by adding the line below to ensure if the gApp is really free or not .
If gApp is Nothing
Then Log("gApp is free")
Else
Log ( "gApp is not free")
Endif
Even after this check it shows gApp is free which does not seem to be the case .
What can I further do to make sure the object is really made NULL !!!!
Going crazy with VB
regards
redindian
|
|
|
|
|
dharani wrote: Going crazy with VB
Then please post your question in the correct forum! This has nothing to do with C/C++/MFC.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
dealing with outlook is especially difficult.
first you need to attempt to connect to running instance and if successfull set a flag.
if not current instance create one.
do your stuff.
then if you connected to running instance just free your stuff and go bye bye.
if you created an instance call close on it and then go bye bye.
NEVER call close on an instance you didnt create.
|
|
|
|
|
Roger Broomfield wrote: dealing with outlook is especially difficult.
I have not found this either in C++ or C#, the latter being especially easy.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
What I found, was that Outlook 2007, was unfriendly. It is a single instance multi process application that needs to be specifically closed. If you start it, you close it, if you dont specifically close an instance you started it sits in running processes until you log off. If you dont start it, you dont close it, but you do release all instances of objects you created. Maybe this is because I dont have the latest VS. But I dont see how that would affect the Outlook object model.
|
|
|
|
|
I use the
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
to check the memory leak, but it output a lot of non-useful info, Is there good way to check where the memory leak?
|
|
|
|
|
normally when u create project in Visual studio ,and after debugging it (ofcourse in debug mode) , when u close the app, Visual studio will shows any unfreezed memory in the output window( ALT+CTRL+ O).
sometimes this information is sufficient to detect the memory leak(depends on codes and the persons knowledge)
if u r trying to find memory leak and vs's output is not sufficient try using boundsckecer or similar softwares ( http://en.wikipedia.org/wiki/BoundsChecker) . Boundschecker is not free.
visual leak detector is a free one(http://www.codeproject.com/KB/applications/visualleakdetector.aspx)
hopes this helps.
If u can Dream... U can do it
|
|
|
|
|
HI
This macro can only report the memory leak that has been made by new.
www.logicsims.ir
|
|
|
|
|
Assuming you have no calls to calloc and malloc, ...
http://stackoverflow.com/questions/3509214/overloading-new-and-delete-in-c
An exception could be the source of the problem since class destructors are not called if an exception is encountered and not handled.
|
|
|
|
|
I'm partial to GlowCode[^]. If you have a few hundred dollars to invest, I'd recommend it.
L u n a t i c F r i n g e
|
|
|
|
|
Thanks for all your reply.
Happy new year. 
|
|
|
|
|
Generally I prefer UMDH. Its free from microsoft and works great.
We can customize memory leak detections to some UI operations, a DLL.
|
|
|
|
|
How to let the code be more elegant? Just too much delete.
BTW, while not to deal the exception in side the function, try catch finally can't be used.
void f()
{
char * buf = new char[128];
...
if (...)
{
delete []buf;
throw runtime_error("...");
}
...
if (...)
{
delete []buf;
throw runtime_error("...");
}
}
=====================
I think what I need is something like constructor and destructor, but for a function.
By overriding operator() of a class may solve some problem, but the function it hard to be re-entrantable, and other misc problems.
Most of the cases the function should be short, so this couldn't be a problem, but in some rare case, it has to deal a lot of data,
and the function looks very long.
modified on Friday, December 24, 2010 3:38 AM
|
|
|
|
|
The try-catch block is the most elegant solution, why cannot you use it?
Alternatives are the C-like goto and the if chain you depicted.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
