UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Gui Functions Class, Any Version    
 
   
jleach
post Sep 24 2011, 10:13 PM
Post#1


UtterAccess Editor
Posts: 9,801
Joined: 7-December 09
From: Staten Island, NY, USA


The attached files are a compilation of GUI related procedures packed into a singleton class and a standard module for globals.
The GUI class must be imported, not copy/pasted, as there are VB attributes to expose the class which can't be set from within Access.
Usage couldn't be simpler with singleton classes: ?GUI.ScreenResVertical()
Attached File  demo_screenshot.gif ( 56.58K )Number of downloads: 913

The main reason behind the creation of this class was to open an explorer window and place it on the screen in a generalized position. This was functionality Mark and I wanted to use with the Drag Drop entry earlier posted to the Code Archive.
Upon working out all the API requirements and having to contend with different coordinate systems for window placement and sizing features, it made sense to abstract the code out of the DragDrop stuff so it can be used anywhere else without having to re-code anything.
Besides the window placement, the initial version of the class focuses on providing method to easily work with rectangle structures: converting them from absolute to relative settings, specifying widths and heights instead of Rights and Bottoms, offsetting, aligning, so on and so forth.
The API makes extensive use of the RECT structure for working with windows placements. The GUI class employs a custom PLACEMENT structure, which is similar to a RECT but instead of a left, top, right and bottom, it uses a left, top, width and height. This makes it much easier to keep coordinates straight when trying to work with windows.
Another implementation of the API which is given much consideration in this class is the actual coordinate measuring when working with windows: they're either based on the Screen Coordinates (from the top left corner), or on the Work Area (the "usable desktop area" - the space not occupied by the start menu, toolbars, etc). The API uses either or depending on circumstance. The functionality in the GUI class makes it easy to return in either coordinate system, or transfer dimensions or structures from one to the other. It is a partial abstraction of the two systems.
Additionally, there's functions to convert Pixels to Twips and vice versa (based on the actual monitor device pixel settings, as it should be done).
Forthcoming functionality includes:
- Sizing with Anchors: resize a window based on an anchor: top, bottom, center, left, right. Currently all resizes are based on the top left corner of the rectangle
- Cursor position functionality: getting based on screen, work area, or Access window coordinates
- Multiple Monitor support: place and resize windows on a secondary monitor, etc
The following is a list of the current procedures (V1.1.0):
AlignPlacement - aligns a placement structure to the specified top and left positions
AlignRect - aligns a rect structure to the specified top and left positions
BrowseForComputer - uses clsBrowseFolder to browse for a computer on the network
BrowseForFolder - uses clsBrowseFolder to call the standard folder browse dialog
BrowseForNetwork - uses clsBrowseFolder to browse for a network folder (hides local folders)
CloseWindow - closes the window of a given handle, if it is open/valid
GetOpenFile - uses clsGetOpenFile to open a basic Open File dialog
GetSaveFile - uses clsGetSaveFile to open a basic Save File dialog
IsToolWindow - determines if a window is a toolbar
IsWindowVisible - determines if the window is visible (regardless of min/max setting)
OpenExplorer - Opens the Explorer window to an optional default folder, returns the handle to the window
PlacementToRect - converts a Placement struct to a Rect struct
RectCenterHorizontal - gets the center point of a rectangle, either in absolute or relative coordinates
RectCenterPointAbsolute - gets the absolute center of a Rect in a Point structure
RectCenterPointRelative - gets the relative cetner of a Rect in a Point structure
RectCenterVertical - gets the vertical center of a Rect structure, either in absolute or relative coordinates
RectToPlacement - converts a Rect structure to a Placement structure
PixelsPerInch - reads the monitor device settings to determin the pixels per inch in the specified direction
PixelsToTwips - converts a Pixel value to a Twips value in the specified direction
ScreenResHorizontal - gets the screen's horizontal (X) resolution
ScreenResRect - gets a Rect structure with the screen coordinates
ScreenResVertical - gets the vertical (Y) resolution of the screen
SetPlacementSize - sets a Placement structure's Width and Height members as specified
SetWindowGeneralPlacement - sets a window to a generalized place on the screen, optionally setting the explict placement, size and stretching in either direction
SetWindowHeight - resizes the height of a window
SetWindowPlacement - sets a window position and size based on the specified Placement structure
SetWindowRect - sets a window position and size based on the specified Rect structure
SetWindowWidth - resizes the width of a window
ShiftPlacement - offsets a placement structure position by the specified amount
ShiftPlacementSize - changes a placement structure's width and height as specified
ShiftRec - offsets a Rect structure by the specified amount (without changing the size of the rect)
ShowDesktop - Minimizes all windows (same as clicking ShowDesktop icon)
ShowDesktopUndo - Restores all windows to their placements before ShowDesktop was called
ShowWindow - sets display and activation state of a window as specified
TwipsToPixels - converts Twip values to Pixels values in the specified direction
WindowBottom - gets the bottom edige of a window from the top edge of the specified coordinates (screen or work area)
WindowClassName - gets the class name of the specified window
WindowExists - determines if the specified window handle is valid
WindowHeight - gets the height of the specified window
WindowLeft - gets the left edge of a window from the left edge of the specified coordintes (screen or work area)
WindowPlacement - gets a placement structure of the specified window
WindowRect - gets a rect structure of the specified window
WindowRight - gets the right edge of the window from the left edge of the specified coordinates (screen or work area)
WindowState - gets the specified window's ShowWindow value (min/max/hidden/active etc)
WindowTop - gets the top edge of the window from the top edge of the specified coordinates (screen or work are)
WindowWidth - gets the width of a window
WorkAreaBottom - gets the bottom edge of the usable desktop area from the top edge of the screen
WorkAreaHeight - gets the height of the usable desktop area
WorkAreaLeft - gets the left edge of the usable desktop area from the left edge of the screen
WorkAreaRect - gets a rect structure of the usuable desktop area in relation to the screen
WorkAreaPlacement - gets a placement structure of the usable desktop area in relation to the screen
WorkAreaRight - gets the right edge of the usable desktop area from the left edge of the screen
WorkAreaTop - gets the top edge of the usable desktop area from the top edge of the screen
WorkAreaWidth - gets the width of the work area
Please inform me of any other useful functionality that may be added and I will see about having them included.
Thanks! Enjoy,
Files:
v1.1.1 (32bit & 64 bit (Thanks Mark))
- GUI v1.1.1 no External Classes.mdb A2K format containing GUI with the functions requiring classes commented out
- GUI v1.1.1 with External Classes.mdb A2K format containg GUI with all related classes
v1.1.0 (32bit only)
- GUI v1.1.0 no External Classes.mdb A2K format containing GUI with the functions requiring classes commented out
- GUI v1.1.0 with External Classes.mdb A2K format containg GUI with all related classes
v1.0.1
- modGUI.bas: the standard module required for globals
- GUI.cls: the GUI singleton class module
- GUI Demo.mdb: Access 2000 format demo of the SetWindowGeneralPlacement function
The V1.0.1 zip folder contains an Access 2010 64 bit demo as well as a text output of 64bit (VB7) version of the GUI class provided by CyberCow (thanks Mark)
Attached File  GUI_v1.1.1.zip ( 203.45K )Number of downloads: 292
Attached File  GUI_v1.1.1_Acc2010_64bit.zip ( 192.77K )Number of downloads: 135

Attached File  GUI_v1.1.0.zip ( 277.42K )Number of downloads: 304

Attached File  GUI_V1.0.1.zip ( 183.25K )Number of downloads: 139

Attached File  GUI_V1.0.0.zip ( 159.91K )Number of downloads: 139

Attached File(s)
Attached File  2161610_Revisions.zip ( 1.01K )Number of downloads: 73
 
Go to the top of the page
 
jleach
post Oct 2 2011, 10:57 AM
Post#2


UtterAccess Editor
Posts: 9,801
Joined: 7-December 09
From: Staten Island, NY, USA


Ideas for future versions:
Currently the method of obtaining the explorer handle is based on searching visible explorer handles and finding the one we just opened: I'd like to remove the 'visible' condition, which would allow us to open the window hidden, set it's size/placement properties, then show it.
- V1.0.1 opens explorer and retrieves the handle of it: while not set up, this can be done with any window/application, provided you know it's classname (it has to know the classname to get the handle, and you need the handle to place/size the window). I could add functionality to open any app and return the handle to it's main window, or...
- If we use CreateProcess instead of Shell (or ShellExecute) to start an app, we can get the handle to the window directly from the process, instead of using the current EnumChildWindows, which requires the classname of the desired window to be known. This would be cool: you could open virtually any application or window, and position and size it accordingly, without needing to know anything except the command to open it.
- Cascading & Tiling windows of both Top Level (desktop windows) and MDI Child windows (windows inside Access or other apps)
If you have any other suggestion feel free to let me know!
Cheers,
Go to the top of the page
 
einalteryid
post Jun 8 2012, 09:28 PM
Post#3



Posts: 139
Joined: 27-March 11



I must be really slow.
I'm trying to get a form to move to the left (or the right) without changing its present top value. This works fine with pop-up and dialogue forms:
Dim lngWindowHandle As Long
lngWindowHandle = Forms![Form].hwnd
GUI.SetWindowGeneralPlacement lngWindowHandle, PlaceXLeft, PlaceYUnspecified, , , , , 0
However it doesn't work with ordinary forms. Each time I press the command button the form goes to the left of the screen but also moves by increments down the screen. I just want it to go to the left hand horizontal but stay in the same place vertical.
Can you help?
Thanks.
EAY
Go to the top of the page
 
jleach
post Jun 8 2012, 10:05 PM
Post#4


UtterAccess Editor
Posts: 9,801
Joined: 7-December 09
From: Staten Island, NY, USA


What is the bahavior of the Y-placement? Is it "stepping down" the same amount each time you call it? About how much is is stepping down? The first thing that comes to mind is the differences between screen coordinates, the top level window coordinates (the access app) and the client rectangle coordinates (the usable area of the access app). By chance, does it appear to be stepping down about the same height of the access titlebar?
If you're trying to place a form within the Access window, you may find the builtin MoveSize command to be easier to manage. The MoveSize command handles the task of placing a form specifically. The GUI stuff was approached from more of an "external" (not MDI) perspective. This isn't to say that it can't work, but just to note that the greater majority of testing was done based on positioning top level windows such as IE on the screen, or the Access window itself, so on and so forth.
If MoveSize for some reason doesn't accomplish what you need, please post back with the most detailed information possible regarding any trends observed in the movement of the top edge of the window, as well as the procedure that's responsible for calling the GUI function.
Cheers,
Go to the top of the page
 
einalteryid
post Jun 8 2012, 10:21 PM
Post#5



Posts: 139
Joined: 27-March 11



Thank you for replying so soon. I've worked with the code on a programmatic level and it worked fine. It was only when I started using it inside Access itsef that I ran into this problem. And again, it works fine with pop-up and dialogue forms which work like programmatic windows more than regular Access form windows. As far as the step-down that takes place, it appears to be an amount approximately equal to the the total height of the Access Title bar, the menu bar and the Toolbutton bar added together. About an inch. And this is each time I invoke the code. So eventually the form goes off the bottom of the screen. I think this will work if I can determine the current position of the top of the form in the MDI client screen and use that as the value for the Y position in the code. Does that make sense?
Thanks again.
EAY
Go to the top of the page
 
jleach
post Jun 8 2012, 11:09 PM
Post#6


UtterAccess Editor
Posts: 9,801
Joined: 7-December 09
From: Staten Island, NY, USA


Yes, that makes perfect sense. Dialog windows are not part of the MDI, thus they are not being offset (notice you can move a dialog window from Access out of the Access window itself, but not an Access form).
DI (Multiple Document Interface) windows such as Word, Excel and Access objects are contained within the MDI Parent and cannot move outside them (except if they're docked as a floating window, but if I recall correctly that's not an option in the Office suite).
You'll need an API to get the client rectangle of an MDI Parent, which should be the same rectangle as where you're allowed to "fit" the MDI windows inside Access. I don't believe there's one in the GUI class presently... I would advise looking at lebans.com to see if he has anything or maybe mvps.org/access/api. After you've obtained the client rect of the MDI parent, call the placement function, offset it by the difference between this amount and the Access Window Rectangle amount (ie - the height of the title bar).
Let me know if you aren't able to find one - I forget if it's readily available, but I'm quite sure we can come up with it somehow if not. If you do find one and can point me to it I'll see about including it in an update to the GUI class.
hth
edit: note that it's important to base this offset off the actual client area rather than getting the height of the titlebar, which is quite easy to do. You'll need to account for varying amounts of toolbars, etc, which the client rect does for us.
Go to the top of the page
 
einalteryid
post Jun 20 2012, 12:09 PM
Post#7



Posts: 139
Joined: 27-March 11



May I impose on you with one futher question?
Can the procedures in the GUI Functions Class be used to automatically resize a window based on the resolution of the computer screen? So if I create an Access dialog pop-up form on my computer using a resolution of 1024 x 768 can I get it to resize automatically when opened on a different computer with a larger screen? I have code to do this with regular Access forms but it doesn't work with Windows forms.
Thanks a lot.
EAY
Go to the top of the page
 
jleach
post Jun 20 2012, 12:17 PM
Post#8


UtterAccess Editor
Posts: 9,801
Joined: 7-December 09
From: Staten Island, NY, USA


I woud assume it's possible... you have a method to get the current screen res, and you have a method to set the window size/position, so I don't see any reason that, in general, you wouldn't be able to get the X/Y screen dimensions followed by a call to reposition the window, passing those dimensions on appropriately.
However, realize that Dialogs are often treated specially by the OS and may not be so easily sized. For example, Windows may not allow us to resize an Access MessageBox because it is a special type of system window. Maybe it will, but maybe not...
Will SetWindowState to Maximized not be sufficient after the handle is retrieved?
hth
Go to the top of the page
 
einalteryid
post Jun 20 2012, 03:25 PM
Post#9



Posts: 139
Joined: 27-March 11



Alas!
've got the dialog forms to resize using the following in the form's On Open event:
GUI.SetWindowGeneralPlacement lngWindowHandle, PlaceXCenter, PlaceYCenter, , , _
(Me.Form.Width / 566.929133858) * ((atGetdevcaps(8) / 1024) * (566.929133858 * 0.066666667)), _
((Me.FormHeader0.Height / 566.929133858) + (Me.Detail0.Height / 566.929133858) + (Me.FormFooter0.Height / 566.929133858)) _
* ((atGetdevcaps(10) / 739) * (566.929133858 * 0.066666667))
Adjusts perfectly on different sized screens so everything looks OK.
One big problem however: The controls etc. remain the same as the original. They don't resize. So everything is out-of-proportion. I think I can overcome this problem if I write some code that rolls through all the controls and adjusts each one of them individually using the same approach as above. I think this will work but boy, have I got a headache already.
Please let me know if you have any further thoughts.
Thanks a lot as always.
EAY
Go to the top of the page
 
BananaRepublic
post Jun 20 2012, 04:00 PM
Post#10


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


If you're on Access 2007 or later, experiment with horizontal & vertical anchoring. This can give you a quick way to resize controls without resorting to code.
Go to the top of the page
 
einalteryid
post Jun 20 2012, 05:47 PM
Post#11



Posts: 139
Joined: 27-March 11



No, I'm afraid I'm still on Access 2003.
Go to the top of the page
 
jleach
post Jun 22 2012, 05:18 AM
Post#12


UtterAccess Editor
Posts: 9,801
Joined: 7-December 09
From: Staten Island, NY, USA


In versions without anchoring (2003 and earlier) the only way to handle it is by writing code to loop all controls. There are some third party tools to handle this. One that I have seen recommended is ShrinkerStretcher from Peter's Software. It has very good reviews among experts, though it is not a free solution.
Cheers,
Editor's note: off-topic portions of this thread will be moved to a separate thread in the near future.
Go to the top of the page
 
jleach
post Aug 15 2012, 05:42 AM
Post#13


UtterAccess Editor
Posts: 9,801
Joined: 7-December 09
From: Staten Island, NY, USA


Updated to V1.1.1 for a bug fix where WindowHeight always returned 0:
!--c1-->
CODE
'
'V1.1.1 - 2012-08-15
'       - Fixed bug in GUI.WindowHeight, had an extra "=" in there
'         so it was always returning 0
'         Changed this line:
'             WindowHeight = r.Bottom = -r.Top
'         to this:
'             WindowHeight = r.Bottom - r.Top
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    12th December 2017 - 03:18 AM