|
why cant you , if you dont see a window tht does mean one ap does nt hv a window, anyway tht is not my problem what is ma problem is i knw from external program the hwnd value and i want to use tht value in ma application to send message to tht hwnd value, any idea
|
|
|
|
|
As said earlier. You can use SendMessage . if you have handle to that window. No matter if its hidden.
swarup wrote: knw from external program the hwnd value and i want to use tht value in ma application to send message to tht hwnd value, any idea
Then what problem?
|
|
|
|
|
i know i have to use sendmessage, but how to code it in my application, now dont tell me use this way SendMessage(2222, "any message","any message","any message");
how to use a hwnd value returned or shown by spy++, in the VC++ program programaticaly
|
|
|
|
|
swarup wrote: how to use a hwnd value returned or shown by spy++, in the VC++ program programaticaly
Mentioning SPY++ from start leads to confusion. You can look in to this[^] article, to see how to get windows handle.
Alternatively, you can use FindWindow() , if you have title to window in question.
|
|
|
|
|
no i dont want sample for spy, i can make spy++,
1st ? can there be a window with out name
2nd dont u think there are windows or application who has a window but hidden.
so in tht case how to get there handel
you query in SPY++ and you come to know about the handel value
now you want to hard code tht value in your app and send some message
for this do u have any idea or it cant be done ?
|
|
|
|
|
CPallini wrote: Actually he can, if the app has the window hidden.
Yes, But I was concerned about "if application does not have window" statement.
|
|
|
|
|
In fact, his words where a bit inaccurate. Anyway what he was asking was enough clear, at least to me...
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.
|
|
|
|
|
CPallini wrote: Anyway what he was asking was enough clear, at least to me
It was not clear, atleast for me ..
I was assuming from start, he has way to get window handle. But he was asking for it in actual.
|
|
|
|
|
thanks guys,
i dont need the program anymore
|
|
|
|
|
Hi everybody,
I have encountered a strange problem, and I don't even know why it is happening. Anyways, I have a dialog box that has a progress bar, and some static controls that show the elapsed time, percentage...and such. Now, I start a new thread and do the work, and update the static controls with SetDlgItemText (this is no MFC app, just Win32 and ATL). Now the static controls displays the text correctly only the first time, and later on the new text draws over the previous one, and after a while static controls just show a complete mess! I discovered that if I open any other window in front of my window, and then move it away, the static controls will briefly show the text correctly, but then again is the same. I suppose it got something to do with the messages those controls are receiving, but can't figure out why. It is as if the controls are drawing the text, but not deleting the previous one.
Thank you.
|
|
|
|
|
You could try forcing a repaint by calling
::InvalidateRect(hwdDlg, NULL, TRUE);
::UpdateWindow(hwdDlg);
each time you update the status (change the controls).
|
|
|
|
|
No, it didn't help, but thank you.
|
|
|
|
|
Why InvalidateRect or UpDateWindow didnt work?
|
|
|
|
|
I really don't know. This is what I have done:
::InvalidateRect( hWndPercent, NULL, TRUE );
::UpdateWindow( hWndPercent );
If I do this:
Invalidate(TRUE)
then the static controls are displaying text correctly, but I am redrawing the whole dialog so I also have a terrible flickering.
Thanks.
|
|
|
|
|
mike holleywell wrote: Invalidate(TRUE)
then the static controls are displaying text correctly, but I am redrawing the whole dialog so I also have a terrible flickering.
Try ::InvalidateRect(hWndPercent, NULL, FALSE) so the background doesn't get redrawn every time.
Sorry about that.
|
|
|
|
|
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.
|
|
|
|
|
You might be better off posting a message from your worker thread to your UI thread, and then having the UI thread do the SetDlgItemText call.
Some Windows functions automatically switch threads and do the SendMessage call for you. Typically, in a worker thread, you don't want to change threads just to update the screen.
You want to hand the update off, and get back to the worker thread's task as quickly as possible. Using PostMessage with a user-defined message is the way to do that.
Software Zen: delete this;
|
|
|
|
|
Okay, thank you for your answer, I will give it a try right now. This is the same as in Visual C# where you have to use Invoke to update the window item from another thread, as the main thread owns the UI.
Thank you, let's see if it works.
|
|
|
|
|
Hi,
I'm trying to integrate an executable application (e.g. the game Solitaire) in a Visual c++ application I created and I was wondering if this is possible and if so, how I could go about doing it (code wise)?
Also, if anyone has knowledge of embeding music (i.e. that can be selected) into a visual c++ window, would be of good help.
Thanks
ibs
|
|
|
|
|
Include what you want as a resource, then write it back to the disk at runtime and use.
Nobody can give you wiser advice than yourself. - Cicero
ப்ரம்மா
|
|
|
|
|
The program is rendering graphics fine, but for some reason it isn't showing colors. Please take a look...probably a stupid mistake. I just can't find it.
CGameWin::CGameWin() : CGameKeyBindingDialog("CKeyboardDialog")
{
Create(NULL, "Ard-Ri", WS_OVERLAPPEDWINDOW,
rectDefault, NULL, "Game");
CGameKeyBindingDialog.setMainWnd(this);
OffSetX, OffSetY = 0;
CBitBackground.CreateBitmap(150, 150, 1, 0, NULL);
CBitXO.CreateBitmap(100, 100, 1, 0, NULL);
InitBrushPen();
OnPaint();
mem_DC.CreateCompatibleDC(ScreenPtr);
DrawBackground();
}
CGameWin::~CGameWin()
{
mem_DC.SelectObject(CBitBackground);
mem_DC.DeleteDC();
mem_DC.SelectObject(CBitXO);
mem_DC.DeleteDC();
DeleteBrushPen();
}
void CGameWin::DrawBackground()
{
CPen* PreviousPenPtr = NULL;
mem_DC.SelectObject(CBitBackground);
mem_DC.PatBlt(0, 0, 150, 150, WHITENESS);
//switch pen
PreviousPenPtr = mem_DC.SelectObject(&BlackPen);
//begin drawing
DrawMonoLine(&mem_DC, 0, 50, 150, 50);
DrawMonoLine(&mem_DC, 0, 100, 150, 100);
DrawMonoLine(&mem_DC, 50, 0, 50, 150);
DrawMonoLine(&mem_DC, 100, 0, 100, 150);
//end drawing
//restore previous pen
mem_DC.SelectObject(&PreviousPenPtr);
mem_DC.SelectObject(CBitXO);
mem_DC.PatBlt(0, 0, 100, 100, WHITENESS);
PreviousPenPtr = mem_DC.SelectObject(&OBluePen);
DrawMonoLine(&mem_DC, 5, 5, 45, 45);
DrawMonoLine(&mem_DC, 5, 45, 45, 5);
mem_DC.SelectObject(&PreviousPenPtr);
}
void CGameWin::DrawMonoLine(CDC* Surface, int srcX, int srcY, int destX, int destY)
{
Surface->MoveTo(srcX, srcY);
Surface->LineTo(destX, destY);
}
void CGameWin::InitBrushPen()
{
BlackPen.CreatePen(PS_SOLID, 5, RGB(0, 0, 0));
OBluePen.CreatePen(PS_SOLID, 2, RGB(0, 0, 255));
XGreenPen.CreatePen(PS_SOLID, 2, RGB(0, 255, 0));
}
void CGameWin::DeleteBrushPen()
{
BlackPen.DeleteObject();
OBluePen.DeleteObject();
XGreenPen.DeleteObject();
}
void CGameWin::RefreshOffSet()
{
CRect WindowArea;
GetClientRect(&WindowArea);
OffSetX = WindowArea.right / 4;
OffSetY = WindowArea.bottom / 4;
}
afx_msg void CGameWin::OnPaint()
{
CPaintDC Screen(this);
ScreenPtr = &Screen;
RefreshOffSet();
mem_DC.SelectObject(CBitBackground);
Screen.BitBlt(OffSetX, OffSetY, 150, 150, &mem_DC, 0, 0, SRCCOPY);
mem_DC.SelectObject(CBitXO);
Screen.BitBlt(OffSetX, OffSetY, 45, 45, &mem_DC, 0, 0, SRCCOPY);
}
class CGameWin : public CFrameWnd
{
public:
CGameWin();
~CGameWin();
afx_msg void OnPaint();
//file menu "File"
afx_msg void OnExit();
//graphics
void DrawBackground();
void RefreshOffSet();
private:
CPaintDC* ScreenPtr;
CBitmap CBitBackground;
CBitmap CBitXO;
CDC mem_DC; //memory device context
CGameKeyBindingDialog CGameKeyBindingDialog;
int OffSetX;
int OffSetY;
//graphics
void DrawMonoLine(CDC* Surface, int srcX, int srcY, int destX, int destY);
//brushes and pens
void InitBrushPen();
void DeleteBrushPen();
CPen BlackPen;
CPen XGreenPen;
CPen OBluePen;
DECLARE_MESSAGE_MAP()
};
|
|
|
|
|
CBitBackground.CreateBitmap(150, 150, 1, 0, NULL);
CBitXO.CreateBitmap(100, 100, 1, 0, NULL);
Why is the bitcount set to 0 in these calls?
What happens if you use
CBitBackground.CreateBitmap(150, 150, 1, 24, NULL);
CBitXO.CreateBitmap(100, 100, 1, 24, NULL);
?
|
|
|
|
|
Some problems (I've mentioned these to you before, I guess you don't believe me)
Calling OnPaint() directly from your constructor is useless. CPaintDC are special DCs used only
in response to a real WM_PAINT message.
In your OnPaint() method you are setting ScreenPtr to point to an object that goes out of scope
when the method exits. If all you are using ScreenPtr for is to create a screen-compatible DC
then how about just getting a screenDC and use that to create your mem DCs?
When creating your background bitmaps you can use CreateCompatibleBitmap instead of CreateBitmap.
It'll make performance better, although performance isn't an issue using WM_PAINT for drawing.
|
|
|
|
|
Listen, I don't have reference books on MFC, all I have to go by is a tutorial book and the MSDN. I'm modifying the tutorials and obviously they aren't very good. The book isn't detailed at all and I don't have an instructor anymore to help. I'd appreciate some slack. I'll correct the program when I get back from work. Can you recommend a message that would work better than WM_PAINT? Can your recommend any other changes?
|
|
|
|
|
I'm not trying to come across as giving you a hard time. Only being direct and to the point
(after all, I don't get paid for this ).
I can recommend some changes. Are you going to be repainting often (like animation or other
frequent redraws) or does your window contents just stay static unless another window is dragged
across it and it needs to be repainted? That'll help in how performance critical the
implementation needs to be
|
|
|
|
|