Maximizing windows underneath my form - vb.net

I have a toolbar that is always on the top (topmost = true) but when i maximize other programs the top of their windows is hidden behind it. I want them to maximize BENEATH my toolbar so i can close/minimize them etc... Like an upside down taskbar, literally changing the screen working area...
Is this possible? I have seen it done in "Cairo Shell"

I don't think you achive by use TopMost property of Form. Instead you may need to use SetWindowPos() WIN32 API call
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int X, int Y, int cx, int cy, SetWindowPosFlags uFlags);
static readonly IntPtr HWND_TOPMOST = new IntPtr(-1);

If you want to reserve an area on the desktop for your program and make all other programs not use that area when maximized, then you have to register your app to Window's appbar list with the API SHAppBarMessage
I havent found any good code to do this in .Net but if you google it maybe you'll be lucky.
Here are one:
http://www.tek-tips.com/viewthread.cfm?qid=1202570&page=1

Related

mouse_event vs real mouse event ( gameing bot )

background :
I wrote a bot to play poker in pokerstars.com. Since 2022 09 14 , the simulation for mouse-move and mouse-click is not working any more.
code:
I used below c# statement to make a click.
enum MouseEventFlag : uint
{
Move = 0x0001,
LeftDown = 0x0002,
LeftUp = 0x0004
}
declaration
[DllImport("user32.dll", EntryPoint = "mouse_event")]
static extern void mouse_event(MouseEventFlag dwFlags, int dx, int dy, int cButtons, int dwExtraInfo);
call
mouse_event(MouseEventFlag.LeftDown | MouseEventFlag.LeftUp, 0, 0, 0, 0);
current situation :
when I need to play a CHECK action, I used to click the CHECK
BUTTON / or it is simulated by my program-bot with mouse_event()
called.
now : the simulation do not work, it looks like ANY PROGRAMMED actions is EATTEN by the pokerstar application. but I can still
click the CHECK BUTTON manually.
I did a search about topics in stackoverflow, experts saying there is NO DIFFERENCE between the manual/simulation click.
any hint to solved this? thanks

Window management in C#

I am using selenium c# for web automation and I am having a problem arranging windows. See attached image of what am trying to achieve.
After a While, I found a workaround.
Every time a window is opened I get its handle by
[DllImport("user32.dll", SetLastError = true)]
private static extern IntPtr GetForegroundWindow();
and store it.
I get the size of the screen by:
int h = (int)Screen.PrimaryScreen.Bounds.Height;
int w = (int)Screen.PrimaryScreen.Bounds.Width;
I divide the screen and arrange the windows as needed using the function:
[DllImport("user32.dll", SetLastError = true)]
internal static extern bool MoveWindow(IntPtr hWnd, int X, int Y, int nWidth, int nHeight, bool bRepaint);
Results

How do I draw to the window's title bar in C++.NET?

I'm trying to draw a custom title bar, and I've read that in order to paint outside a window's client area, I need to override WndProc and handle the WM_NCPAINT message. Currently, I'm doing that like this:
//WndProc override
virtual void WndProc(Message% m) override
{
switch(m.Msg)
{
case 0x85: //WM_NCPAINT
case 0x0A: //WM_PAINT
//Call original
System::Windows::Forms::Form::WndProc(m);
//Now we'll do our painting
DrawTitleBar(m.HWnd);
break;
default:
System::Windows::Forms::Form::WndProc(m);
break;
}
}
Which works, because I can put a breakpoint in and it gets hit. If I remove the call to the original, the window's frame isn't drawn. DrawTitleBar looks like this:
void DrawTitleBar(IntPtr hWnd)
{
IntPtr hDC;
Graphics^ g;
//Get the device context (DC)
hDC = GetWindowDC(hWnd);
//Get the graphics
g = Graphics::FromHdc(hDC);
//Draw
g->FillRectangle(Brushes::Blue, 0, 0, 100, 10);
//Cleanup
g->Flush();
ReleaseDC(hWnd, hDC);
}
I first get the DC from the window handle. Then I get the Graphics object by using Graphics::FromHdc. I release the DC with ReleaseDC. Incase there's an issue here, this is how I import the native Win32 functions:
[DllImport("user32.dll")]
extern IntPtr GetWindowDC(IntPtr hWnd);
[DllImport("user32.dll")]
extern int ReleaseDC(IntPtr hWnd, IntPtr hDC);
Also: I've tried a bunch of different methods, all with the same results. I can find a bunch of C# and VB examples on the web, but no C++ examples. I've also read about Windows Vista compatibility being an issue with this sort of thing. Currently, I don't care about that, as I will add it later.
Two simple facts. 1. under DWM GetWindowDC is essentially broken.
2. Two work arounds partially exist A. set compatiblity mode to xp or 98 or 95.
B. program example in msdn social exists. search for
"GetWindowDC broken" then follow a lengthy url to a code
sample [fix the broken url by adding a trailing ) ].
Unhappily, the window shows up with rounded corners on
my box build 9200, win 8.0 , no updates.

CF TreeView - Selected Item when control loses focus

I know that "HideSelection" property is missing in CF.
But i still need to handle situation when an item is selected that it remains selected (greyed) even when the control looses focus.
I have tried using this peace of code, but with no success. I get an exception in GetFocus() method and i dont know what im doing wrong.
Any help is much appreciated !
[DllImport("User32.dll")]
static extern IntPtr GetFocus();
[DllImport("User32.dll")]
static extern Int32 GetWindowLong(IntPtr hwnd, Int32 integer1);
[DllImport("User32.dll")]
static extern IntPtr SetWindowLong(IntPtr hwnd, Int32 integer1, int integer2);
private bool doneOnce;
protected override void OnGotFocus(System.EventArgs e)
{
base.OnGotFocus(e);
if (this.itemsTreeView != null)
{
this.itemsTreeView.Focus();
if (doneOnce == false)
{
doneOnce = true;
IntPtr hWnd = GetFocus();
Int32 lS = GetWindowLong(hWnd, -16);
lS = lS | 0x20;
SetWindowLong(hWnd, -16, lS);
}
}
}
I have put this code in my "code behind" view that holds TreeView control.
Windows CE uses coredll.dll instead of user32.dll.
Some functions are equal on both platforms, while some are not implemented for Compact Framework. I usually check http://www.pinvoke.net for the declares.

How to get HWND of a windowless ATL control?

I created a ATL windows less control and the class definition is like this:
class ATL_NO_VTABLE CRSPClient :
public IObjectSafetyImpl<CRSPClient, INTERFACESAFE_FOR_UNTRUSTED_CALLER|INTERFACESAFE_FOR_UNTRUSTED_DATA>,
public CComObjectRootEx<CComSingleThreadModel>,
public IDispatchImpl<IRSPClient, &IID_IRSPClient, &LIBID_axBanckleRSPClientLib, /*wMajor =*/ 1, /*wMinor =*/ 0>,
public IPersistStreamInitImpl<CRSPClient>,
public IOleControlImpl<CRSPClient>,
public IOleObjectImpl<CRSPClient>,
public IOleInPlaceActiveObjectImpl<CRSPClient>,
public IQuickActivateImpl<CRSPClient>,
public IViewObjectExImpl<CRSPClient>,
public IOleInPlaceObjectWindowlessImpl<CRSPClient>,
#ifdef _WIN32_WCE // IObjectSafety is required on Windows CE for the control to be loaded correctly
public IObjectSafetyImpl<CRSPClient, INTERFACESAFE_FOR_UNTRUSTED_CALLER>,
#endif
public CComCoClass<CRSPClient, &CLSID_RSPClient>,
public CComControl<CRSPClient>
Then for some purpose I need to post message to the window. I tried to get the handle of the window in quite many ways and ALL of them failed:
HWND CRSPClient::GetHwnd()
{
HWND hwndRet = NULL;
// hwndRet = m_hWnd;
//IOleInPlaceActiveObjectImpl<CRSPClient>::GetWindow(&hwndRet);
//IOleWindow<CRSPClient>::GetWindow(&hwndRet);
//this->m_spInPlaceSite->GetWindow(&hwndRet);
//CComQIPtr<IOleInPlaceSite> spSite = this->m_spClientSite;
//spSite->GetWindow(&hwndRet);
//hwndRet = ::WindowFromDC(GetDC());
return hwndRet;
}
Anybody know be there any way to get the HWND?
OMG I'm totally frustrated by microsoft's great ATL framework!
The whole point of the windowless control is that it works without a window handle. If you wanted to use window handle in case it, by any chance, exists and the control falled back into windowed mode, then it's easy: m_hWndCD.
If otherwise you have to have a window, then you have m_bWindowOnly to flag in constructor and indicate that you will need a HWND:
Flag indicating the control should be windowed, even if the container supports windowless controls.
If you still want it windowless and need a window just sometimes, under certain condition that come up on runtime, you always have an option to create a private message only window and dispatch messages through it.
Here is some code taken from Microsoft's Direct3D ATL sample. I haven't tested it yet.
// Get the window we need to use. This will either be the window that has already
// been created if we are window. If we are windowless the HWND of the client
// will be retrieved from the HDC.
void GetOurWindow()
{
// If we're windowless we still need an HWND for Direct3d
if (m_bWndLess)
{
HDC hDC;
// Get the HDC from the client
m_spInPlaceSite->GetDC(NULL, OLEDC_NODRAW, &hDC);
m_hOurWnd = WindowFromDC(hDC);
#if 1
// Code to make VB5 paint properly now it has clipped it's own hDC
RECT rect;
::GetClientRect(m_hOurWnd,&rect);
HRGN hRegion = CreateRectRgn(rect.left,rect.top,rect.right,rect.bottom);
SelectClipRgn(hDC,hRegion);
#endif
m_spInPlaceSite->ReleaseDC(hDC);
}
else
m_hOurWnd = m_hWnd;
}