Scenario: In an Access project a main form has to be positioned and rearranged depending on the size of the Access-Application window. This should be done using VBA.
As far as I know there is no way in Microsoft Access VBA to capture the Restore/Maximize-Event of the Access-Application window (I refer to the Access Window itself not any form inside this).
Is there a way to solve this issue using WIN32 API?
I don't know of any way to use the WIN32 API to capture the Restore/Maximize Event. The best workaround I can think of is to use the Win32 API in conjunction with the Timer event of a form that is always open (either the Main Menu or some hidden form) and periodically poll the main access window to determine whether it's currently maximized.
Enum WindowSize
wsMax = 1
wsMin
wsRestore
End Enum
'Functions return 1 for true and 0 for false; multiply result by -1 to use as Boolean'
Private Declare Function IsZoomed Lib "User32" (ByVal hWnd As Long) As Integer
Private Declare Function IsIconic Lib "User32" (ByVal hWnd As Long) As Integer
Function IsMaximized(hWnd As Long) As Boolean
IsMaximized = IsZoomed(hWnd) * -1
End Function
Function IsMinimized(hWnd As Long) As Boolean
IsMinimized = IsIconic(hWnd) * -1
End Function
Private Sub Form_Timer()
Static PrevWinSize As WindowSize
If IsMaximized(hWndAccessApp) Then
If PrevWinSize <> wsMax Then
'Window has been maximized since we last checked'
MsgBox "Main Access window is maximized"
PrevWinSize = wsMax
End If
ElseIf IsMinimized(hWndAccessApp) Then
If PrevWinSize <> wsMin Then
'Window has been minimized since we last checked'
MsgBox "Main Access window is minimized"
PrevWinSize = wsMin
End If
Else
If PrevWinSize <> wsRestore Then
'Window has been restored since we last checked'
MsgBox "Main Access window is restored"
PrevWinSize = wsRestore
End If
End If
End Sub
You'll need to set an interval in the form's TimerInterval property to control how frequently you need to poll the window size.
EDIT: Obviously you'll want to keep track of the main window's previous state so that you don't do any unnecessary processing. The code as posted reflects this.
Related
I am programming VB6 in Win7. I have a program with a borderless window, no caption, no icon, no control box, etc. just a window. Using a command button, I can minimize the window to the Task Bar, and from there return it back.
My problem is, when minimized to the Task Bar, I right-click on the icon, and I wish to close the program from there. Win7 won't let me close the program via the pop-up menu. The close option is on the menu, but it does nothing.
How can I close this program from the task bar menu?
This seems to be a bug in VB6 Forms subsystem -- when form's BorderStyle is set to none Close menu on the taskbar and Alt+F4 shortcut as well just stop working as there is no system menu on the form.
Unfortunately a workaround involves subclassing and here is one way to deal with the issue:
Option Explicit
Private Const WM_SYSCOMMAND As Long = &H112
Private Const SC_CLOSE As Long = &HF060&
Private m_pSubclass As IUnknown
Private Property Get pvAddressOfSubclassProc() As Form1 '-- change Form1 to current form name
Set pvAddressOfSubclassProc = InitAddressOfMethod(Me, 5)
End Property
Private Sub Form_Load()
Set m_pSubclass = InitSubclassingThunk(hWnd, Me, pvAddressOfSubclassProc.SubclassProc(0, 0, 0, 0, 0))
End Sub
Public Function SubclassProc(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long, Handled As Boolean) As Long
Select Case wMsg
Case WM_SYSCOMMAND
If wParam = SC_CLOSE Then
Unload Me
Handled = True
End If
End Select
End Function
This will need mdModernSubclassing.bas from Moderen Subclassing Thunk repository added to your project for the IDE-safe subclassing implementation.
So I want to use
pid = Shell(MyApp, 1)
with VBA to automate the use of a crappy external program. This program unfortunately has all sorts of annoying dialog boxes and popups that must be clicked. Is there any way to directly control each dialog box to ensure that the "OK" button is pressed rather than "Cancel"?
Currently I am using
AppActivate pid
Application.SendKeys ("%R")
But this command can only guarantee the "OK" of the initial pop-up dialog. Subsequent pop-ups may not be clicked, especially because I'm not sure how to guarantee focus on the new popup. Is there a way to find the child process ID's of any new popups? Is there any way to directly "click" a particularly labeled control button?
How to Interact with a Button on a Dialog
Well, there is a way of sending a WM_COMMAND message to common buttons on a dialog box effectively closing it:
Declare Function SendMessageA Lib "user32" (ByVal hWnd As Long, ByVal Msg As Integer, ByVal wParam As Long, ByVal lParam As Long) As Long
Declare Function FindWindowA Lib "user32" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Const WM_COMMAND As Integer = 273
Const WM_CLOSE As Integer = 16
Const IDOK As Integer = 1
Const IDCANCEL As Integer = 2
Sub ShowDialogs()
If Shell("C:\Users\myself\dialogs.exe") <> 0 Then
Dim hWnd As Long
hWnd = FindWindowA("#32770", "Info")
Debug.Print hWnd
SendMessageA hWnd, WM_COMMAND, IDOK, 0
End If
End Sub
Important Notes:
I had to use Spy++ to find out what class name Windows gives to message box dialogs.
The Windows SDK headers contained useful constants, especially the value for WM_COMMAND which was obtained from WinUser.h.
Each time a dialog is a created, you will need to obtain the handle for the window again using FindWindowA, as shown in the preceding code.
hello
i'm using Visual Basic 2008
here is part of my code:
Private Const SW_HIDE As Integer = 0
Private Const SW_SHOW As Integer = 5
<DllImport("user32.dll", SetLastError:=True, CharSet:=CharSet.Auto)> _
Private Shared Function ShowWindowAsync(ByVal hwnd As IntPtr, ByVal nCmdShow As Integer) As Boolean
End Function
button1 code:
Try
Dim p() As Process = Process.GetProcessesByName("notepad")
Dim mwh = p(0).MainWindowHandle
ShowWindowAsync(mwh, SW_HIDE)
Catch ex As Exception
MsgBox("error")
End Try
button2 code:
Try
Dim p() As Process = Process.GetProcessesByName("notepad")
Dim mwh = p(0).MainWindowHandle
ShowWindowAsync(mwh, SW_SHOW)
Catch ex As Exception
MsgBox("error")
End Try
when i click button 1 ( to hide the window ) it works good, but then when i want to display window back ( by clicking button 2 ) the function returns FALSE, who can tell me why? and how to get it to work, to hide window and then to show it again?
Because ShowWindowAsync() returns zero when the window was previously hidden according to the MSDN documentation, and zero is interpreted as FALSE. The return value does not indicate whether the function succeeded or not.
So the first time you call ShowWindowAsync(mwh, SW_HIDE) on a visible window the function returns TRUE because ShowWindowAsync() returns a non-zero value indicating the window (that is now/will be hidden) used to be visible.
Then the second call ShowWindowAsync(mwh, SW_SHOW) on a hidden window returns FALSE because ShowWindowAsync() returns a zero value indicating the window (that is now/will be visible) used to be hidden.
In other words, this is by design and the function should work as intended (unless the mwh window is not responding to messages or is invalid).
But the real problem here is that once you hide a window, Process::MainWindowHandle property doesn't have the handle anymore.
A process has a main window associated
with it only if the process has a
graphical interface. If the associated
process does not have a main window,
the MainWindowHandle value is zero.
The value is also zero for processes
that have been hidden, that is,
processes that are not visible in the
taskbar. This can be the case for
processes that appear as icons in the
notification area, at the far right of
the taskbar.
What you should do is to obtain the window handle via p(0).MainWindowHandle once and save the returned handle somewhere, so that you can show/hide the window. Of course, you should make sure that you zero out the saved handle when the window gets destroyed by the target process. In Notepad's case, you can use the Process::Exited event.
Sounds like "by design". Don't treat the return value of "false" as an error.
As per MSDN:
If the window was previously visible, the return value is nonzero.
If the window was previously hidden, the return value is zero.
http://msdn.microsoft.com/en-us/library/ms633549%28VS.85%29.aspx
You could likely block the exception from occurring by declaring the interop import of the function as a 32-bit integer type instead of a Boolean.
Private Shared Function ShowWindowAsync(ByVal hwnd As IntPtr, ByVal nCmdShow As Integer) As Integer
When hiding I did :
WindowHandle = Proc(0).MainWindowHandle
ShowWindowAsync(Proc(0).MainWindowHandle, ShowWindowConstants.SW_HIDE)
Then when showing I used the WindowHandle variable:
ShowWindowAsync(WindowHandle, ShowWindowConstants.SW_SHOW)
To Maximize a hidden window of another process you must do this 3 steps (very easy):
1- Get the MainWindowHandle
Because the application is hidden the MainWindowHandle is 0 (false). To overcome this problem you can use the FindWindow
//Get the MainWindowHandle
IntPtr hwnd = FindWindow(null, <WINDOW TITLE>);
2- Use ShowWindowAsync()
bool result = ShowWindowAsync(hwnd, 3); //3= Maximize application
3- Implement one of this application events: "GotFocus", "Activated" or "IsVisibleChanged"
(I only tested the "Activated" event)
private void WindowApplication_Activated(object sender, EventArgs e)
{
Application.Current.MainWindow.Show();
}
You can find more information on this url:
http://isolvable.blogspot.pt/2009/09/restoring-wpf-window-of-another-process.html
Hope this information can help someone!
How to add a popup menu on a VB 6.0 borderless form?
Every time I add a menu, the border reappears, even when BorderStyle is set to vbBSNone and the menu is hidden.
It's doable, but somewhat unsatisfying (to me). By having any menu properties in a form, the border will default back to visible. There are, however, a few workarounds:
1) The method I think you'll prefer involves making a second form that you'll never really "use" or see. Put the menu on that second form, and then call that menu from the form you actually want to use. Assuming you're using Form_MouseDown to call this, here's the code:
Private Sub Form_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
If Button And vbRightButton Then PopupMenu Form2.mnuYourMenu
End sub
You will have to remember to unload this second form from memory, however.
2) Another way, only using the first form, would be to set the form's ControlBox to False and to leave the Caption property blank. This "removes" the border when BorderStyle is set to 0... I put removes in quotes because it will unfortunately leave behind a 1-pixel black line. It doesn't look bad, but it might not be a viable solution for you.
3) The final way, which I read about but haven't done anything with myself, would be to use the CreatePopupMenu API, found at http://allapi.mentalis.org/apilist/CreatePopupMenu.shtml
Hope this helps!
For the benefit of anyone else who comes here looking for an answer to this problem, here is a very simple API method that works:
Declarations:
Private Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" _
(ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long
Private Declare Function GetWindowLong Lib "user32" Alias "GetWindowLongA" _
(ByVal hwnd As Long, ByVal nIndex As Long) As Long
Const GWL_STYLE = -16, WS_BORDER = &H800000
In Form_Load:
SetWindowLong Me.hwnd, GWL_STYLE, GetWindowLong(Me.hwnd, GWL_STYLE) And Not WS_BORDER
This is possible. Set the form's BorderStyle to None, Caption to an empty string, ControlBox, MaxButton MinButton to False. Then, using VB6's menu editor, create a top-level menu named "mnuPopup," and set its Visible property to False. Create the rest of the menu as submenus to that top-level menu, setting their Visible properties to True. Then, in the code for the form, you can display the menu with PopupMenu menuPopup. It looks like this:
I have a vb6 form with an ocx control on it. The ocx control has a button on it that I want to press from code. How do I do this?
I have:
Dim b As CommandButton
Set b = ocx.GetButton("btnPrint")
SendMessage ocx.hwnd, WM_COMMAND, GetWindowLong(b.hwnd, GWL_ID), b.hwnd
but it doesn't seem to work.
I believe the following will work:
Dim b As CommandButton
Set b = ocx.GetButton("btnPrint")
b = True
CommandButtons actually have two functions. One is the usual click button and the other is a toggle button that acts similar to a CheckBox. The default property of the CommandButton is actually the Value property that indicates whether a button is toggled. By setting the property, the Click event is generated. This is done even if the button is not styled as a ToggleButton and therefore doesn't change its state.
If you have access to the OCX code, you could expose the associated event handler and invoke it directly.
Don't know if an equivalent of .Net Button's Click() method existed back in VB6 days
For keypress you can also use sendmessage sending both keydown and keyup:
Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Long) As Long
Const WM_KEYDOWN As Integer = &H100
Const WM_KEYUP As Integer = &H101
Const VK_SPACE = &H20
Private Sub cmdCommand1_Click()
Dim b As CommandButton
Set b = ocx.GetButton("btnPrint")
SendMessage b.hWnd, WM_KEYDOWN, VK_SPACE, 0&
SendMessage b.hWnd, WM_KEYUP, VK_SPACE, 0&
End Sub
This:
Dim b As CommandButton
Set b = ocx.GetButton("btnPrint")
b = True
does work. Completely unintuitive. I'd expect it to throw an error since a bool is not a valid CommandButton, but it is because of the default property thing.
WM_LBUTTONDOWN would be a mouse click, what I want is a button click (button as in a hwnd button, not a mouse button).
I don't have access to the source of the ocx (it's a 3rd party control). If I did, I would expose the function that I wanted to call (the original writer of the ocx should have exposed it).
Do you have access to the OCX code? You shouldn't really be directly invoking the click of a button. You should refactor the code so that the OCX button click code calls a function, e.g.
CMyWindow::OnLButtonDown()
{
this->FooBar();
}
Then from your VB6 app, directly call the FooBar method. If you can't directly call functions from VB6 you can wrap the FooBar() method with a windows message proc function, e.g.
#define WM_FOOBAR WM_APP + 1
Then use SendMessage in the VB6, like SendMessage(WM_FOOBAR, ...)