|
I just tested the following and it works in VS6.
HINSTANCE handle = ShellExecute(0, "print", "C:\\WorkOrder.html", NULL, NULL, SW_SHOW );
The only down side that I see here is it prompts the user with the printer settings dialog. All they have to do is click print but still...
ZeePain! wrote: This seems like one of those programs that started small, grew incrementally, building internal pressure, and finally barfed all over its source code sneakers. Or something.
thedailywtf.com[^]
-- modified at 10:00 Thursday 8th December, 2005
|
|
|
|
|
Hi,
How to open recent files from file menu in MFC application.Which method do we need to override?
|
|
|
|
|
If I understood this question then, here I say...
Just create one MenuItem in your File popup menu with this id.
you can give name something as "Recent Files"
ID_ FILE_MRU_FILE1
To know more about how it works and all, view this Microsoft link its pretty clear
http://www.microsoft.com/msj/0899/c/c0899.aspx[^]
regards,
-OP
|
|
|
|
|
right click in C drive and create a file called "hello.txt" and a folder called "New Folder". Then run this program:
BOOL ret = MoveFileWithProgress("C:\\hello.txt", "C:\\New Folder", NULL, 0, MOVEFILE_COPY_ALLOWED);
DWORD dw = GetLastError();
ret = MoveFile("C:\\hello.txt", "C:\\New Folder");
dw = GetLastError();
Both the MoveFile* calls fail with error ERROR_ALREADY_EXISTS. According to MSDN the target can be either a file or a directory. It is not clear what is going wrong, any ideas anyone?
thanks!
|
|
|
|
|
Hi,
The new file name must not already exists. This is in case of MoveFile.
When the dwflag parameter of MoveFileWithProgress is set MOVEFILE_COPY_ALLOWED it internally uses MoveFile() and DeleteFile() functions. Hence, you get the same error.
Bye,
Cool Ju 
Dream Ur Destiny
|
|
|
|
|
Never mind, I identified the problem.
If the source is a file, the target has to be a file name too, it cant be a directory. I misunderstood the MSDN doc for MoveFileWithProgress.
Btw, It is MoveFile and MoveFileEx that call MoveFileWithProgress and not the other way.
thanks!
|
|
|
|
|
Hi,
The MoveFileWithProgress function is equivalent to MoveFileEx. It doesn't get called by MoveFileEx. MoveFileWithProgess simulates CopyFile() [which i mentioned as MoveFile mistakenly] and DeleteFile when the dwflag is set to MOVEFILE_COPY_ALLOWED.
Bye,
Cool Ju
Dream Ur Destiny
|
|
|
|
|
And I use the 3D geometry model to calibrate the camera.
I need to know at least for given pairs of known corresponding scene and image points.
Four scene points I can measure, but I don't know how to determine the coordinate of four corresponding image points.
I'm using VideoOCX for to work with image porcessing in Visual C++
Can anybody help me to determine the coordinate image point (in pixel)???
Best Regard
H Anh
|
|
|
|
|
Hi,
Why can't I pick up WM_THEMECHANGED message when user change the visual style from "Windows Classic" to "Windows XP"? In the reverse direction, which is from XP style to Classic, it worked properly. Is there any special line of code needed to pick up this kind of message?
Thanks in advance.
|
|
|
|
|
That sounds weird. I know I get the message in my apps, and I don't do anything special.
--
Pictures[^] from my Japan trip.
|
|
|
|
|
I use FindWindow function in windows appl_2 to get the handle of windows appl_1. However lpWindowName cannot be use since my windows appl_1 contains version number which will change everytime I recomplie it. I used the class object name inherit "theapp" which does not work. Can anyone please tell me how to get the lpClassName from appl_1 please? Thank you.
|
|
|
|
|
The more relevant questions is WHY do you need to do this?
Because if you need HWND_1 from APPL_2, why not write HWND_1 into a memory mapped file that can be directly read from APPL_2 and then not EVER have to worry about it again. Avoiding the CHEESY FindWindow function altogether. Nuff said
I AM going to have to write an article titled FindWindow - JUST SAY NO!
|
|
|
|
|
Why not let appl_2 probe for appl_1 with window messages? Use RegisterWindowMessage() to register a unique window message which only your two apps know. A unique message name could be created using Guidgen.exe which comes with visual studio.
#define YOUR_MAGIC_COOKIE 0xdeadbeef
#define UNIQUE_NAME "AUniqueName"
#include "common.h"
UINT nMessage = RegisterWindowMessage(UNIQUE_NAME);
foreach hWnd in TopLevelWindows {
if(YOUR_MAGIC_COOKIE == SendMessage(hWnd, nMessage, 0, 0)) {
DoSomethingWithYourWindow(hWnd);
}
}
#include "common.h"
UINT nMessage = RegisterWindowMessage(UNIQUE_NAME);
switch(msg.message) {
...
case nMessage:
return YOUR_MAGIC_COOKIE;
}Please translate appl_1's message handling into your preferred toolkit's way of handling messages.
--
Pictures[^] from my Japan trip.
-- modified at 18:46 Tuesday 6th December, 2005
|
|
|
|
|
Either of your methods is better than FindWindow(). Using memory mapped file looks clean but I am not too familiar with it. RegisterWindowMessage() seems easy enough for me to pick up quick.
Thanks a million, guys!
|
|
|
|
|
Bzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzt....
foreach hWnd in TopLevelWindows { <br />
if(YOUR_MAGIC_COOKIE == SendMessage(hWnd, nMessage, 0, 0)) {
This will hang your application if the top-level window you sent a message to is not responding.
Better use the other technique, or else at LEAST use SendMessageTimeout.
|
|
|
|
|
 You're right!
--
Pictures[^] from my Japan trip.
|
|
|
|
|
Another solution is to use HWND_BROADCAST and register another response message. Then collect the result in a/the message loop.
--
Pictures[^] from my Japan trip.
|
|
|
|
|
vitowong wrote: Either of your methods is better than FindWindow(). Using memory mapped file looks clean but I am not too familiar with it.
Have a look at this thread before using FindWindow api!-
PROS AND CONS of FINDWINDOW[^]
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
( must be a dumb day for me ... )
I have a CImageList that I use in a Tree Control; the bitmap contains non-mask images all bundled in one big bitmap; I create the imagelist like :
il.Create( IDB_TREE_IMAGES, 16, 0, RGB(0,128,128) );
il.SetBkColor( GetSysColor(COLOR_WINDOW) );
SetImageList( &il, TVSIL_NORMAL );
This works well, all images are drawn transparently.
I want to split the big bitmap into individual smaller bitmaps, why ? because it's easier to add and remove images from the image list by adding and removing individual images instead of having to remove and resize the big image.
so, I do this :
m_ImageList.Create( 16, 14,ILC_COLOR4,30, 10 );
CBitmap bm;
bm.LoadBitmap(ITB_TREE_COORDINATE);
COORDINATE_IMAGE_INDEX = m_ImageList.Add( &bm, RGB(0,128,128) );
bm.DeleteObject();
...
m_ImageList.SetBkColor( GetSysColor(COLOR_WINDOW) );
SetImageList( &m_ImageList, TVSIL_NORMAL );
but in this second case, the images are not drawn transparently; the bitmaps are 256 colors palettized bitmaps.
Any ideas ?
in my example that works, there is not specification for the type of images ( ILC_COLOR, ... ) and for my second example, I need to specify one, is there a default type I can/should use ?
Thanks.
Max.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
You're supposed to use ILC_MASK in the Create() call together with your color format (e.g. ILC_COLOR8).
--
|
|
|
|
|
Hi:
I am trying to do what I thought would be a simple thing. I have a dialog which contains a variety of controls. One of my controls is an edit box. When a user is entering data through this control, I would like the user to be able to press the "ENTER" key to accept what has been entered.
I understand that dialogs will execute their DEFAULT button when "ENTER" is pressed but I THOUGHT that if I derived a new CMyEdit from CEdit and found the right function to override, I would be able to intercept the "ENTER" key and have it process the input instead. I must find a way to do this because I have users that feel that pressing enter after making an entry into a control like this is a natural thing to do and it is natural to expect that the input should be processed at that point. Frankly, I somewhat agree...
Is it my imagination or is this impossible? I have overridden every CEdit virtual function that I can find and NONE of them are called when I press "ENTER". Some of them are called if I press other keys, but not "ENTER".
What gives? What am I doing wrong?
Thanks in advance for your help!
Mark
-- modified at 14:33 Tuesday 6th December, 2005
|
|
|
|
|
Use the ES_WANTRETURN style.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
Hi David. Thanks for your response.
I did try this already. It made no difference. As it turns out, the VS help item that discusses "Want Return" says:
"This style has no effect on a single-line edit-box control."
I am using a single line edit box so I guess that explains it. I really don't want to use a multiline box so I am still stuck with this problem.
Thanks,
Mark
|
|
|
|
|
In the context of a single-line edit control, the enter key makes no sense. It should do the default behavior, which is to dismiss the dialog.
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
Well, I guess there is an "old school" that feels that pressing ENTER means "Take this input and process it". Some feel that it should then move the focus to the next item in the TAB order. It makes some sense to me although I would like nothing more at this point then to tell my users that this is the "new school" and "get over it". Unfortunately, I don't think they are going to drop this issue. I wish I could find a way...
Thanks again,
Mark
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
