|
|
Hi, I have two windows processes and one sends (posts) a mesage to the other to activate it etc. When the main app gets this message it calls SetForegroundWindow() to bring the app to the foreground so it is the active/on top application.
The problem is SetForegroundWindow() is failing (returning 0) and my app stays in the background. I've also tried BringWindowToTop().
The WinXP Task Bar flashes the Icon for my app.
I'm going nuts here.
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
That's how XP works. It flashes the taskbar instead of having the application take over the screen. If you can, try your App. on a Win 98 machine just to make sure it's XP and not your code.
|
|
|
|
|
|
|
Well my initial hopes have been dashed. It appears to work when I run the App in the Debugger, but not otherwise.
I think the problem is the first app is stealing back or not relinquishing focus. I have another path I'm about to head down.
I use SetForegroundWindow() at other times in the App to restore from the System Tray for example and they work fine.
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
|
Hi Scott,
Thanks for that. I'd never heard of SwitchToThisWindow().
This sort of works, however there are two problems. First the Task Bar pops-up (I have it to Auto-Hide) and flashes the app icon. Second and worse is if I Alt+Tab to another app afer my app has come to the foreground using SwitchToThisWindow() then cause my app to activate using SwitchToThisWindow() the aforementioned app is activated not mine. This is a killer.
Finally SwitchToThisWindow sends the previous app to the bottom of the Z-Order which seems very strange. AFAIK this isn't what SetForegroundWindow() does.
I can't believe something as simple as this is causing me so much grief.
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
As others have said this is the way XP is supposed to work; users don't like have the rug window they are working in being pulled away without warning. However, if you are certain you have a really good reason to do it (warning of an impending nuclear strike or the re-election of Dubbya), you can (usually) do it this way:
BOOL StealFocus(CWnd *pWnd)
{
DWORD ForeGroundID = GetWindowThreadProcessId(::GetForegroundWindow(), NULL);
DWORD CurrentID = GetCurrentThreadId();
BOOL bRet = AttachThreadInput(ForeGroundID, CurrentID, TRUE);
pWnd->SetForegroundWindow();
pWnd->SetFocus();
AttachThreadInput(ForeGroundID, CurrentID, FALSE);
return bRet;
}
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Hi Phil,
Thanks for the reply. I couldn't get this to work reliably either as indicated in an earlier reply. It worked in the debugger, but not outside.
Both of these apps are mine, so I just need the ability to get one to bring the other to the foreground. I've read up on all the issues and what MS is trying to do and why and I'm basically ok with that. But in my case I'm not pulling any rugs out from under anyone but myself.;)
I have a solution which seems to work, but I'm not as happy as I'd like with it. I'm about to try doing the SetForgroundWindow() in in App A to get it to bring App B to the foreground and my understanding is this should work. Up untill now I was trying to get App B to bring itself to the foreground.
This is the start of a new day for me (here in Oz) which I hope will be better than yesterday.
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
It works fine for me in and out of the debugger as a way for an application to bring itself to the foreground. I simply have StealFocus(this) in a dialog that shows a vital message.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
Phil J Pearson wrote:
It works fine for me in and out of the debugger as a way for an application to bring itself to the foreground. I simply have StealFocus(this) in a dialog that shows a vital message.
What version of Windows are you using? Does this bring the app to the foreground or just the dialog? I assume both as one will follow the other but need to ask.
I'm using XP with SP1. I'm also using a P3 550Mhz box which tends to show problems that newer, faster machines don't.
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
It works on Windows 2000, XP, XP SP1a and XP SP2 on a range of hardware from Celeron 300 onwards.
It brings the whole app to the foreground.
The opinions expressed in this communication do not necessarily represent those of the author (especially if you find them impolite, discourteous or inflammatory).
|
|
|
|
|
I need to modify the style of a window owned by another application under Windows 98/ME and XP/2000. I can get it to work under XP, but not 98.
Windows XP
In XP (and hopefully 2000) the following code works:
DWORD dwStyle, dwError;
if (dwStyle = GetWindowLongPtr (hWnd, GWL_STYLE))
{
dwStyle &= ~(WS_TILEDWINDOW | WS_CHILD | WS_POPUP);
dwStyle |= WS_BORDER | WS_OVERLAPPED;
SetLastError (0);
if (0 == SetWindowLongPtr (hWnd, GWL_STYLE, dwStyle) && 0 != (dwError = GetLastError ()))
{
CString csMess;
csMess.Format ("SetWindowLongPtr Failed: %lX", dwError);
AfxMessageBox (csMess, MB_ICONSTOP);
}
}
To make this work in XP I first have to set some privileges as below:
bool CTools::SetPrivileges ()
{
bool bRet = false;
HANDLE hToken;
if (OpenProcessToken (GetCurrentProcess (), TOKEN_ADJUST_PRIVILEGES, &hToken))
{
TOKEN_PRIVILEGES tPriv;
tPriv.PrivilegeCount = 1;
if (LookupPrivilegeValue ("", SE_DEBUG_NAME, &tPriv.Privileges[0].Luid))
{
tPriv.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
if (AdjustTokenPrivileges (hToken, FALSE, &tPriv, NULL, NULL, NULL) &&
GetLastError() == ERROR_SUCCESS)
bRet = true;
}
CloseHandle (hToken);
}
return bRet;
}
Windows 98
Under Windows 98 these don't work. SetWindowLongPtr returns 0 (usually non-zero when it works) but GetLastError returns 0 too. More importantly, the style doesn't change. GetWindowLongPtr does work though. There may be a permissions problem in 98 like there was in XP but SetPrivileges is not relevant to 98.
Documentation does say:
"Windows 95/98/Me: The SetWindowLong function may fail if the window specified by the hWnd parameter does not belong to the same process as the calling thread."
I also tried this, without success in 98 or XP (even with priveleges set):
CWnd::ModifyStyle (hWnd, WS_TILEDWINDOW | WS_CHILD | WS_POPUP, WS_BORDER | WS_OVERLAPPED, 0);
In XP it indicates failure with it's return value. In 98 it pretends to work but the style doesn't change. Does anyone know another way to change a windows style?
I don't know what to do to set the style of a window my application doesn't own under Win 98. Any ideas? Thanks in advance!
Alex Gibbs
|
|
|
|
|
I don't know which version of MFC you're using, but CWnd::ModifyStyle doesn't have a parameter for window handles. According to Microsoft documentation (msdn.microsoft.com/library/default.asp), the function is defined as:
BOOL ModifyStyle(DWORD dwRemove, DWORD dwAdd, UINT nFlags = 0);
So you don't need a window handle, just a CWnd pointer to the application in question (I don't know how to do that myself, but I'm sure other forum members can help) .
|
|
|
|
|
I too saw that only the one you mentioned is documented. I found the other when Dev Studio showed two forms to choose from when I was typing it in. Going to the declaration takes you to afxwin.h in the CWnd declaration:
static BOOL PASCAL ModifyStyle(HWND hWnd, DWORD dwRemove, DWORD dwAdd, UINT nFlags);
which of course also has:
BOOL ModifyStyle(DWORD dwRemove, DWORD dwAdd, UINT nFlags = 0);
I tried both forms under 98 and neither worked. Both now work in XP though. At least it was another thing to try.
Alex Gibbs
|
|
|
|
|
Here is an update. I can modify another window's style under XP using any of the calls below, if the priveleges are set as mentioned in the first post:
<br />
SetWindowLongPtr (hWnd, GWL_STYLE, dwStyle);<br />
CWnd::ModifyStyle (hWnd, dwRemove, dwAdd, 0);<br />
pCWnd->ModifyStyle (dwRemove, dwAdd);<br />
However, none of them change the visible appearance of a window under 98. Remember I am trying to change the window of another process. I think the problem is one of priveleges/permissions in 98.
I found something else that might be relevant at MSDN, but I don't think it is the problem. MSDN Article, 5th paragraph: "Windows 95/98/Me automatically adds and removes the WS_EX_WINDOWEDGE style for windows in all applications. ..."
Anyone able to help with priveleges/permissions in 98?
Alex Gibbs
|
|
|
|
|
It's possible that the window of another process "undos" any changes made to it. I know of some programmers who put code in their MFC applications to prevent certain window style changes. I believe the Windows Media Player exhibits this behaviour.
If this other process is of your own creation, then you may want to use user-defined messages to invoke certain behaviour.
|
|
|
|
|
Hello all. I need some help regarding add-ins.
I want to create an Add-in for the Visual Basic Editor (open any Office application and hit Alt+F11 to see what I'm talking about). I also want to make it using Visual C++ since that's what I'm familiar with.
I don't have any experience with ATL/COM (yet), so if anyone out there can provide some information I would be very greatful. A step-by-step guide would also be helpful. At the very least, some links/code snippets to get me started.
Thank you.
|
|
|
|
|
I think that's a great idea also. Most of my co-workers use VB6 and they wish they had a way to use macros like in .Net or VC6.
[insert witty comment here]
bdiamond
|
|
|
|
|
I have found an example that uses C++/ATL to make a COM add-in for Office, but I'm new to ATL/COM and am having difficulties understanding it. If you do a search on msdn.microsoft.com for "comaddin.exe" you'll find it.
|
|
|
|
|
I've finaly figured out how to get the window shape for a visual style.
By going through the GetThemeBackgroundRegion, I can retrieve a handle to a HRGN class. Then I use GetRegionData from the class to retrive the structure mentioned above, which should give me a collection of rectangles. However, i'm mildly confused.
This is the content of the MSDN:
The RGNDATA structure contains a header and an array of rectangles that compose a region. These rectangles, sorted top to bottom left to right, do not overlap.
typedef struct _RGNDATA { /* rgnd */
RGNDATAHEADER rdh;
char Buffer[1];
} RGNDATA;
Parameters
rdh:
Specifies a RGNDATAHEADER structure. (For more information on this structure, see the Platform SDK.) The members of this structure specify the type of region (whether it is rectangular or trapezoidal), the number of rectangles that make up the region, the size of the buffer that contains the rectangle structures, and so on.
Buffer:
Specifies an arbitrary-size buffer that contains the RECT structures that make up the region.
Now... the confusing part is. Where is the array of RECT? It's a single element array of Char.... Is there some special approach to this, or is it a typo / mistake? And what does "arbitary size buffer" mean? I know it's a retrieved value, but I need to marshal it in C#, so kind of need the additional information.
Cheers guys.
Cata
|
|
|
|
|
I have a small utility app that I'm making using ReadDirectoryChangesW() (thanks to DavidCrow). Here's the function:
UINT WatchFolder( LPVOID pDlg )
{
try
{
USES_CONVERSION;
CBRFolderWatcherDlg* pd = (CBRFolderWatcherDlg*) pDlg;
HANDLE hDir = CreateFile( gstrPath,FILE_LIST_DIRECTORY, FILE_SHARE_READ|FILE_SHARE_DELETE, NULL,
OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS,NULL );
FILE_NOTIFY_INFORMATION Buffer[1024];
DWORD BytesReturned;
while( ReadDirectoryChangesW(hDir,&Buffer,sizeof(Buffer),TRUE,
FILE_NOTIFY_CHANGE_CREATION|FILE_NOTIFY_CHANGE_LAST_ACCESS|FILE_NOTIFY_CHANGE_LAST_WRITE|
FILE_NOTIFY_CHANGE_SIZE|FILE_NOTIFY_CHANGE_ATTRIBUTES|FILE_NOTIFY_CHANGE_DIR_NAME|FILE_NOTIFY_CHANGE_FILE_NAME,
&BytesReturned, NULL, NULL) )
{
CTime tm = CTime::GetCurrentTime();
switch(Buffer[0].Action)
{
case FILE_ACTION_ADDED:
int i=0;
do
{
CString strTime;
CTime tm = CTime::GetCurrentTime();
strTime = tm.Format("%m/%d/%Y %I:%M %p");
CString buf = CString(Buffer[i].FileName).Left(Buffer[i].FileNameLength / 2) ;
int nRow = pd->m_lvw.GetItemCount();
nRow = pd->m_lvw.InsertItem(nRow,buf);
pd->m_lvw.SetItemText(nRow,1,strTime);
i++;
}while (!Buffer[i].NextEntryOffset);
break;
}
}
}
MYCATCHALL
return 0;
}
I call this function using AfxBeginThread(). It works, but right now the only way for the thread to stop executing is to end the app. I thought to make a global variable that I could set if I clicked a 'Cancel' button, but that doesn't work because ReadDirectoryChangesW() doesn't finish executing until it receives a notification, at which time it continues through the loop. I'm trying to find if there's a way I can do something like this:
<br />
m_pThread = AfxBeginThread(WatchFolder,this);<br />
<br />
EndThread(m_pThread);
Any help is appreciated. Thanks in advance
[insert witty comment here]
bdiamond
|
|
|
|
|
I would suggest reworking the directory watching code to use an overlapped scheme. Then youc na wait on 2 events - one for the overlapped IO to be ready, and another signaled by your program to exit the thread.
If your overlapped event is set, then get the overlapped result and process the data.
If the thread exit event is set, then cancel the overlapped request and leave your thread normally.
|
|
|
|
|
I've now created my thread suspended, then start it with a call to m_pThread->ResumeThread() . Then when the user clicks 'Cancel' I call SuspendThread() and then delete() on the CWinThread object. It works (meaning that files no longer show up), and I don't get any type of errors in my debug window when I terminate the app. So is this okay?
[insert witty comment here]
bdiamond
|
|
|
|
|