|
YOUR FEEDBACK
Did you read today's front page stories & breaking news?
SYS-CON.TV SYS-CON.TV WEBCASTS |
POWERBUILDER LINKS YOU MUST CLICK ON Techniques Dockable Windows in PowerBuilder
Another PowerBuilder challenge
By: Brad Wery
Jan. 30, 2006 12:00 PM
If you've read any of my past articles, you know that I love a good challenge, a challenge that really gets me thinking and ultimately ends up teaching me something. One thing I always wanted to do was create dockable windows using pure PowerScript. I held off from doing this for some time because of the almost overwhelming complexity that was inherent with this type of control. Seeing as this would be the perfect test of my skills, I motivated myself to do it.
Here is what I observed using the System Tree as an example:
Once you have the source take a look at dockwindows.pbl. There are three objects that represent the three main components outlined above:
n_cst_dockwindowmanager
n_cst_dockwindowmanager It's very important that this object be declared as a global variable like so: n_cst_dockwindowmanager gnv_dockmanager. The variable name in this case is very important; this is how it'll be referenced in the other objects. There are a few key functions that you should be aware of that will help you interact with the docked windows. Review the code in each function for a better understanding of what's happening:
This window will be the ancestor of all your docked windows. Inherit one for every new window you require for your application. Once inherited and saved you will need to determine its position. Its position will dictate how you initially size the window. Windows docked to the left or right should have narrow widths. Windows docked to the top or bottom should have short heights. Take a look at w_dockpblselect and w_dockoutput for an example. W_dockpblselect docks to the left and w_dockoutput docks to the bottom. Your new window should only have one control placed on it. Resizing and positioning of this control is done automatically. This is done by simply creating a reference to the fifth element in the control array within the open event of the window (i.e., ido_object). If more than one control is required, you must encapsulate everything into a custom visual user object and place that onto the window. Take note of the windows event list. You will see two new user events: ResizeEnd and Resizing. Both are called from the Other event. Resizing is triggered before the Resize event and lets us know how the user is sizing the window (e.g., left edge, right edge, top edge, etc.). ResizeEnd is triggered once the user is finished sizing the window. The Resizing event is used to restrict the user in how they can size the docked window. If the window is docked to the left, you would only want them to resize by dragging the right edge, not the left, top, or bottom. If they are resizing from the wrong edge, the window stops drawing and is repositioned to its proper location. The ResizeEnd event will allow the window to start drawing if necessary. While looking at the event list you may have noticed two other user events: PositionChanging and PositionChanged. PositionChanging is called before a window is repositioned by the user. You can prevent the window from being repositioned by returning 1 from this event. PositionChanged is called after the window's position has changed. Arguments in both events are integers that are represented by the LEFT, RIGHT, TOP, and BOTTOM constants found in n_cst_dockwindowmanager. Both user events are triggered from the of_SetPosition function. The drag outline appears when a user clicks on the window's title bar and starts dragging. Refer to of_DragWindow to see exactly how this is managed. The SetCapture and ReleaseCapture Windows API functions are used to direct all mouse activity to the window title bar. By doing this, the mouse can leave the window and still trigger the MouseMove event of the title bar, which in turn makes a call to of_DragWindow.
One other thing to make note of is the visual appearance of the windows title bar. The title bar comprises of the following images; feel free to change them to suite the overall look of your application:
w_outline The open event of the window uses an API call to change the windows style to be layered so that transparency can be added. SetWindowLong(Handle(THIS), GWL_EXSTYLE, WS_EX_LAYERED) Another API call is triggered to convert the Aqua color to transparent.
SetLayeredWindowAttributes(Handle That's it; we now have an outline (see Figure 1). To change the color of the outline you would just change the line color of the rectangle.
Putting It Together
//Declare Global Variable Pay attention to the call to of_ResizeDockWindows in the frames resize event. You can see that the size and position is being set based on having your own homemade toolbars implemented (http://pbdj.syscon.com/read/140739.htm). If you're using the built-in PowerBuilder toolbars, then you will need to set the size and position in a different way. The first argument should be 100 x the number of toolbars visible and the last argument should be the work space height - micro-help height + (100 x the number of toolbars visible).
Conclusion YOUR FEEDBACK
PBDJ LATEST STORIES . . .
SUBSCRIBE TO THE WORLD'S MOST POWERFUL NEWSLETTERS SUBSCRIBE TO OUR RSS FEEDS & GET YOUR SYS-CON NEWS LIVE!
|
SYS-CON FEATURED WHITEPAPERS MOST READ THIS WEEK BREAKING POWERBUILDER / SYBASE NEWS
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||