|
slaindevil wrote: This solved my problem. Thanks...
No problem. I believe your thread was inheriting the threading model of the thread that created it.
Best Wishes,
-David Delaune
|
|
|
|
|
slaindevil wrote:
The only workaround I know, is to start the file dialog in a different thread.
Why not do the opposite - spawn a UI-thread that creates the MTA?
All you need is a message pump and something, e.g. a user defined message, that tells the thread to create the server that should reside in the MTA.
If your post is about the issue Randor mentions, you won't pull the rug for the main thread and all calls to shell functions will not fail because if the MTA at least.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for your idea, but Randors post solved my problem and it fits better into the program code. But really, thanks anyway!
|
|
|
|
|
I created a Gdiplus::Bitmap by Gdiplus::Bitmap::FromHICON(), but the alpha channels lost. Is there any solutions?
Evil.Ghost
|
|
|
|
|
Yes.
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]
|
|
|
|
|
The project style guidelines say this:
"Unless portability and reusability is not a concern, the use of standard integral types is forbidden (exception: enum) and the types from a standard project header must be used."
I can remember the days when we used to do this, but it has fallen into disuse. Are integers more portable now? I remember it being a problem with DEC machines, but we don't use them anymore. It seems I am not following the guidelines right now, I need a good reason in case the code inspectors ask.
In help all it says is that integer size is machine dependent.
------------------<;,><-------------------
|
|
|
|
|
RedSonja wrote: In help all it says is that integer size is machine dependent.
Well, that's an hint.
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]
|
|
|
|
|
I am aware that different machines have different sizes for integer. I was hoping to hear something like - compilers are so clever nowadays they can handle this.
It seems there is no way out and I will have to make a header file with standard types in it. I might have one left from 10 years ago. I was just hoping this kind of stuff was no longer necessary.
(I just surprised the new graduate, who wanted to know what an unsigned character is good for. Apart from using it as an unsigned character, in the old days when size mattered we used to use unsigned char to get an 8-bit integer. That was in image processing, with one integer for each pixel, etc.)
------------------<;,><-------------------
|
|
|
|
|
RedSonja wrote: compilers are so clever nowadays they can handle this.
Well, they are compilers after all (i.e. How 'the fresh Hell' a compiler would handle that?).
RedSonja wrote: (I just surprised the new graduate, who wanted to know what an unsigned character is good for. Apart from using it as an unsigned character, in the old days when size mattered we used to use unsigned char to get an 8-bit integer. That was in image processing, with one integer for each pixel, etc.)
Since there is a rather general agreement among different machines about the size of a byte, then it may be indeed a good starting point.
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]
|
|
|
|
|
I think your determination to be amusing at my expense just exceeded my determination to find help here.
Perhaps among the other readers there are some who understand what my problem is and have dealt with it themselves in the recent past.
The problem is not the code, or the size of integers. The problem is handling the code auditors.
------------------<;,><-------------------
|
|
|
|
|
RedSonja wrote: I think your determination to be amusing at my expense just exceeded my determination to find help here.
Perhaps your question led you to this situation.
You have some rules which, for some reason, you are uhappy with and you expect someone here to give you a technical solution to a non-technical issue.
RedSonja wrote: The problem is not the code, or the size of integers. The problem is handling the code auditors.
And what has that to do with C/C++/MFC?
|
|
|
|
|
If you don't have solution for the question, PLEASE DON'T REPLY.
|
|
|
|
|
codedgn wrote: If you don't have solution for the question, PLEASE DON'T REPLY.
Your statement does NOT compile, error message: missing 'then'. 
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]
|
|
|
|
|
codedgn wrote: If you don't have solution for the question, PLEASE DON'T REPLY.
FWIW I was giving advice, there is no solution to the OP's question.
As someone who only joined the Code Project today, I don't think your opinion on this subject has any merit. May I suggest you read the guidelines[^], and then spend a few months reading some of the questions and answers, before telling others what to do.
|
|
|
|
|
The purpose why people post questions here is to seek solution not advice. The advice they can get from anywhere.
They have adviser in school.
|
|
|
|
|
codedgn wrote: The purpose why people post questions here is to seek solution not advice.
You must either be particularly dense, or you know absolutely nothing about computing! As I stated before there is no solution to this problem, as is the case with many of the questions here. All we can do is advise the OP of that fact and make suggestions as to what other course of action they may take. The fact that the questioner does not like the answer makes no difference to the outcome.
|
|
|
|
|
RedSonja wrote: I think your determination to be amusing at my expense just exceeded my determination to find help here.
My question, actually, was serious: how could you expect a compiler will handle it? Compilers simply cannot.
RedSonja wrote: Perhaps among the other readers there are some who understand what my problem is and have dealt with it themselves in the recent past.
Again, my suggestion was serious: unsigned char is actually one of the most portable data type.
RedSonja wrote: The problem is not the code, or the size of integers. The problem is handling the code auditors.
If there aren't problems with the size of the integers, then shouldn't be problems with the auditors. Well, actually here I can understand your point, anyway is portability really a concern, there? If it is then I suppose you've already solved the problem and can boldly argue with the auditors. On the other hand, if portability isn't really a concern, why ('the fresh hell' again) should auditors worry about (holding this point is more troublesome).
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]
|
|
|
|
|
The compilers will handle whatever, based on the build. One build won't fit all, like you would already know. I don't think that using an integer is such a sin. Yes, the size is dependent on the architecture, but you can always make multiple builds (unless of course your code runs on a really large number of different architectures, and you don't want to maintain a build for every such architecture).
I see no reason to carry those old beliefs today. It doesn't do any harm to use that "standard header" and the datatypes present in it, but it doesn't make any sense either any longer.
Just my 2c.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Actually integer is machine dependent, say for Turbo C it is 16 bit. For Visual C it is 32 bit. So you cannot write a portable with int since it changes its behavior with the machine.
Please refer this article to get more info [^]
Величие не Бога может быть недооценена.
modified on Wednesday, October 28, 2009 6:38 AM
|
|
|
|
|
Hi,
I am creating a COM object in VC++ to take the snapshot of the screen (PrintScreen key functionality) and to send it to the default printer. I could get the screen shot by using the keybd_event() in to the clipboard but I could not find a proper way to print the screen to the default printer.
Can anybody help me in resolving this. Could any one send me the code snippet to do this in ATL COM application?
With Regards,
Abraham Chethuvelil
|
|
|
|
|
|
Thanks David,
Let me ask you one doubt from your code.
You have taken the default printer to the Handle and in the calling area, you have used it with GetPrinter(). I require the function which will work same as the code snippet in VB.
Dim PauseTime, Start
Clipboard.Clear
Call PrintScreenApp
Dim dataPic As Picture
PauseTime = 20 ' Set duration.
Start = Timer ' Set start time.
Do While Timer < Start + PauseTime
Set dataPic = Clipboard.GetData()
DoEvents ' Yield to other processes.
If dataPic <> 0 Then
Printer.PaintPicture dataPic, 0, 0, (Printer.Width - 400)
Printer.EndDoc
Clipboard.Clear
Exit Do
End If
Loop
Set dataPic = Nothing
Can you please help me?
With Regards,
Abraham Jose
|
|
|
|
|
Arun Abraham Jose wrote: Dim PauseTime, Start
Hi Abraham,
Unfortunately VB6 code looks like egyptian hieroglyphics to me. I have always wondered what a Dim is. I searched codeproject and found some C++ code you could copy and paste.
Easy to use class for ScreenCapture to printer[^]
Best Wishes,
-David Delaune
|
|
|
|
|
Hi,
Exactly there lies the problem, some of the functions we found in these samples will not work in ATL application, if I say for example, 'CBitMap' used in the last link you provided is giving error when I use it in my application, but when I try to include afxwin.h, it gives a fatal error saying Windows.h already exists.
When I search through sites, all of them are either used in normal Single Document or Dialog based applications or coded to help in UI based applications. When I use these code snippets in my application it will either throw exceptions or will show syntax errors
Please provide me a solution to this.
With Regards,
Abraham Jose
|
|
|
|
|
Arun Abraham Jose wrote: Please provide me a solution to this.
The MFC framework is nothing more than a thin wrapper around the Win32 equivalents. The CBitmap Class [^] is nothing more than a wrapper around the BITMAP Structure[^].
Anyway have a look at the Capturing an Image[^] sample provided by Microsoft. The CaptureAnImage function in that example is not using any MFC. I'm sure with all the code you are being provided that you can get something working.
Best Wishes,
-David Delaune
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
