Capturing the _Screen Resize Event 2

[wjs2]

I am using a named browse window to display detail records with an 'in Screen' parm. I have the following code in the program (which I obtained from here):

DEFINE CLASS MyHook AS Custom
oScreen = _Screen

PROCEDURE oScreen.Resize && attach VFP code to object's
&& event when this class is
&& initialized
* your code goes here
ENDPROC
ENDDEFINE

* Main program
_Screen.AddObject("oHook","MyHook&quot && now screen resize
&& event captured...

I have not gotten the oScreen.Resize procedure to fire and can't figure out why. Just guessing, the code is not in the correct sequence. The current sequence is:

Define the named window.
execute the AddObject.
The class is defined at the tail end of all code.

There is probably some lunacy involved but I useally have a workround for that condition. It isn't working this time. Any suggestions would be greatly appreciated.

Thanks
Bill

 

[ramani]

HI
I cannot see a RESIZE event for the _screen object which can be manipulated by us directly from VFP.

Methods available...
AddObject, AddProperty, Box, Circle, Cls, Draw, Hide, Line, Move, Point, Print, Pset, Refresh, Release, RemoveObject,
SaveAs, SaveAsClass, SetAll, Show, TextHeight, TextWidth,
ZOrder

ramani
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[wjs2]

Hi Ramani,

This is going to sound a little strange, but, I already have the lunacy disclaimer attached. I changed the oScreen.Resize procedure to reference the window named in the 'Define Window' statement instead of the 'name' clause, and it fired. It wasn't exactly what I expected but now there is something to work with. I'll let you know.

Thanks
Bill

 

[craigsboyd]

I've used the above code myself to use with a resizer class...I put the code in the main.prg before I made the _screen visible and before I brought up my first form in _screen hooked the resize event of the _screen fine...my problem whihc I have currently posted in this forum is when I hook the individual forms' resize events by adding an object as you described it only works for the first form I do this with, all subsequent forms do not get the object added to them properly and the resize event code that I have added also doesn't execute...well anyways, really not an answer to your problem but am working on a very similar thing here and I thought I would comment if for no other reason than to keep this thread at the top Slighthaze = NULL

 

[ChrisRChamberlain]

Bill/slighthaze

I use code similar to yours.

In main.prg

DO SetCommands
DO OpenAppTables
DO SystemVariables
DO SaveSettings
DO DeclareVariables
DO ScreenMovedClass
Do ScreenResizeClass
DO ScreenSetup
DO SystemSetup

where the DO ScreenMovedClass and Do ScreenResizeClass procedures define the classes.

In the .Load() event of the main form :-

_SCREEN.AddObject([oResizer],[Resizer])
_SCREEN.AddObject([oScreenMoved],[ScreenMoved])

By adding a .Moved() method, you can save the coordinates of _SCREEN to a table so that the application always starts with the last coordinates.[/color]

The .Resize() event of any child window has :-

_SCREEN.Resize()

which follows any code specific to the child window.

In _SCREEN.Resize, child forms are individually resized according to the size of their sibling forms or resized according to the size of _SCREEN.

The individual controls within a child form are also resized if required.

I find that by processing all this in the one method, it's easier to maintain.

The title bars from all child windows are removed and _SCREEN.Caption = [Xxxxxx] is used instead.

Resize _SCREEN and the child forms are resized in relation to _SCREEN - resize a child form and you resize any relevant child forms as well as _SCREEN.

FAQ184-2483 - the answer to getting answered.​

Chris

 

[wjs2]

slighthaze,

It has been an interesting day. Tried all kinds of things to get it to work the way I 'thought' it should work. Used srows() and scols() to 'Modify' the window. Threw in some font property changes to _Screen. Nothing seemed to work. Actually made things worse. Finally, on the oScreen.Resize just rebuilt the tempfile and threw it back to the original browse. It works just fine but seems to a very strange way to go about getting it to resize. If there is a better way, would certainly like to know about it. If the tempfile happens to be very large (it isn't typical, but, have seen these things go as high as 600,000 records on the work I'm doing) that is a real drag.

Thanks for keeping the thread alive.
WJS

PS I like NULL. NULL is like forever. It's really big or it's really little. Nobody knows for sure.

 

[ChrisRChamberlain]

wjs2

May be stating the obvious, but have you tried a grid as opposed to a browse?

FAQ184-2483 - the answer to getting answered.​

Chris

 

[wjs2]

Hi Chris,

We must have posted about the same time.

OK. Lets see if I followed that. In my 'Main' prg which is the front end traffic cop, I would define the _Screen.resize which consists of the class definition, the proc and endproc, and enddefine. In the load event of the first form called by the 'Traffic Cop', I would put the _Screen.Adobject commands. At this point, I am at a loss as to what to put in the resize procedure unless I have a class definition for each window that will be resized. Now, what I thought was going to happen was this, if you used the screen resize button in the top right hand corner of the screen to 'Maximize' the Fox Pro _Screen, the _screen would actually be resized first and then the oScreen.resize procedure would be fired. From my testing, this does not seem to be the case. Could you give me an example of the sequence of how these things are fired off? Or, where might I find this informatin in Fox Pro dicumentation?

Thanks,
WJS

 

[wjs2]

Chris,

Well, it may be obvious but I didn't do it. Actually, I thought the 'Name' clause in the window definition would cause it to act like a grid. Looking at the properties, one of the things I tried to get it to work was to change the 'WindowState' of the Named window in the Screen.resize proc. This got some pretty scary stuff to happen but not what I had in mind. I don't remember exactly what it did, but, a few of the things I tried were kind of spooky and I think this was one of them.

WJS

 

[craigsboyd]

What Chris put down is exactly what I had originally...and then I decided since you can hook the resize event of the _screen why not hook the resize event of the forms as they come up...never thought about calling _screen.resize() event from myform.resize() might try that...but anyways when i started trying to hook every form's resize using addobject just like it worked for the _screen I ran into a problem, you can only hook one form's resize event...after that it doesn't work...

WJS2...are you saying that if you put that if you put the following code in your MAIN.prg or whatever you have set to main for your project that the messagebox doesn't come up when you run your program and resize the _screen?

_SCREEN.AddObject('clsBindEvent','clsBindEvent')

DEFINE CLASS clsBindEvent AS Custom
oScreen = _screen
PROCEDURE oScreen.Resize
DoDefault()
messagebox("HELLO WORLD&quot
ENDPROC
enddefine

***JIC - Probably don't need to say this, but make sure you put the DEFINE way at the bottom of your Main.prg so it isn't in amongst executing code***

Post back and let me know what happened...i'm interested to know Slighthaze = NULL

 

[wjs2]

slighthaze,

Originally, I did not think the _Screen.resize was firing. After moving code around, changing the resize code, etc.. etc... I'm not sure that is actually what was going on. Anyway, I will keep you posted on this as the Great and Magnificent Programmer (me) marches to victory over the forces of evil.

As a side note.. For other forms, I did drop the _resizer distributed with VFP 6.0 on my project. In my form init events and resize events (for forms that should be full screen and window state set to maximize) is the code 'ThisForm._resizable.adjustcontrols()'. I haven't studied this code thoroughly as yet but suspect that it will shed some light on what I'm trying to do now. At first, I thought I could use _resizer to resize user defined windows if they were named (since the name makes the window act like a grid in that it gives you an object to work with). This didn't work out as I don't fully understand what _resizer is doing. I will look at this code some more and see if I can figure it out.

A big thanks to you, Chris and Ramani for keeping this thread alive. It has kept me (The Great and Magnificent Programmer, as stated earlier) motivated to destroy the ugly and puny forces of evil.

wjs

 

[ChrisRChamberlain]

On resizing a child form with scrollbars in _SCREEN.Resize(), you will find that it will not always go the dimensions called in the method.

The following code, which would need modiying to suit, resolves the problem

IF VARTYPE(oMain) = [O]
[tab]WITH oMain
[tab][tab].LockScreen = .T.
[tab][tab].Scrollbars = 0
[tab][tab].Height = _SCREEN.Height
[tab][tab].Left = _SCREEN.Left + oEnquiries.Width + 5
[tab][tab].Top = _SCREEN.Top
[tab][tab].Width = _SCREEN.Width - oEnquiries.Width - 5
[tab][tab].Scrollbars = 3
[tab][tab].LockScreen = .F.
[tab]ENDW
ENDI

FAQ184-2483 - the answer to getting answered.​

Chris

 

[ChrisRChamberlain]

wjs

Apologies, I just noticed this :-

'if you used the screen resize button in the top right hand corner of the screen to 'Maximize' the Fox Pro _Screen, the _screen would actually be resized first and then the oScreen.resize procedure would be fired.'

That is what happens. The code in _SCREEN.Resize() should then resize the child forms according to the actual screen resolution.

If you look at the example in the previous post, you will see the resize code specific to one object oMain, which is one of n child forms, so you then need similar code for all the other child forms.

FAQ184-2483 - the answer to getting answered.​

Chris

 

[wjs2]

Fellow Masakissed,

Unfortunately, I must inform you that Great and Magnificent Programmer has been pounded into dust by the ugly and puny forces of evil. Fortunately, same has risen from the ashes of his defeet to once again triumphed over same. What ever that means.

This may be unique to my situation so you will just have to read it and kind of guess. This cannot be the only solution, but, here is my explanation as to what I did.

There are two different object types involved with two distinctly different solutions.
1)The resizing of forms and their controls. For this I used the _resizer class.
2)Resizing a browse window without resizing any controls. I wrote this one. Sort of. I'm not extremely proud of it since it isn't very portable. If you have any suggestions for this, I would appreciate it.

Here is the class definition for resizing a window. (And it does work faster than rebuilding a cursor or temp file.)

This is the code in the 'Main' program of the project.
*--------------------------------------------------------------------------
*..... Resize a browse window inside the main Visual Fox Pro screen
Procedure DefineWindowResize
DEFINE CLASS oScreenHook AS Custom
oScreen = _Screen
PROCEDURE oScreen.Resize && Resize Event Handler
OutputWindow = Woutput()
If OutputWindow = 'W_BROWSEWINDOW'
deactivate window w_BrowseWindow
release window w_BrowseWindow
DO DefineBrowse
endif
ENDPROC
ENDDEFINE
*----------------------------------------------------------------------------

My analysis of why it wasn't working before may be off, but since this worked, I can only surmise that what I was doing before was not enough to actually refresh the window, which is why I thought it was not firing. As you can see, I released the window, then redefined it. The program was in the midst of a 'browse' and control was returned back to the browse once the resize was complete. Which kind of surprised me because that's what I wanted it to do but figured it wasn't doing anything else I wanted so why should it do this? The 'DefineBrowse' is a standard 'Define Window' statement where I use srows() and scols() to define the size of the new window. Since the resize of the _Screen occurrs first, the srows() and scols() reflect the new window size available with menus, toolbars and scroll bars taken into account.

The unelegant part is that I will have to add 'IF' statements inside the class definition for different windows that I want to resize. That's not totally bad since different windows will have different properties, and, I don't neccessaraly want all windows resized. For what ever reason, I could not get this to work with using the window named in the 'NAME' clause instead of the name supplied in the 'DEFINE WINDOW' statement. If you have any ideas, would like to hear that too.

Thanks much folks! If I discover anything else earth shaking on this I will post it here in the next few days.

GaMP,
wjs

 

[craigsboyd]

WJS2,

deactivate window w_BrowseWindow
release window w_BrowseWindow
DO DefineBrowse

...couldn't you use _wsize (VFP API) to resize that window?
or is there a specific reason that you need to release it when the _screen resize event happens? Just a thought, maybe you're not in the mood for external library calls after so valiantly battling the ugly and puny forces of evil. Slighthaze = NULL

 

[wjs2]

Slighthaze,

I hadn't seen the _wsize and had to look it up. Ooooo! C code!! Oooo! Forces of Evil with renewed vigor!

Seriously... Looking at the routine in the Visual Fox 6.0 documentation, it gives the C code, not the Fox code and that doesn't help me much. If this would make the code more portable, which I think it would, I would be happy to give it a shot. Do you know where I might find the Fox code to handle the api call? Did a quick search on this site and took a look on MSDN but didn't see anything except the code included in the Fox documentation.

Thanks,
wjs

 

[craigsboyd]

In the help file it is c code...that's because _wsize is a VFP API function...kind of similar to a Win32 API call, except that instead of declaring the function and calling it from kernel32.dll, user32.dll, etc. you would be calling it from your library...that's why i said external library calls...you can use some of that code and just adjust it to your needs and then compile it into an FLL (or OCX) that you can use from VFP that would resize your window...i could go into it a little more if you'd like, or we could just bow to the forces of evil and call it a day. Read the VFP Help Article entitled "Adding Visual FoxPro API Calls" to get a better understanding about what I am talking about. Slighthaze = NULL

 

[wjs2]

Slighthaze,

Bow to the Forces of Evil? Hadn't thought about it. Hmm. Well, since discretion is the better part of valor, and, I am working on a time limit, for now, I will cede the field of battle and return at a more opportune moment. After I have read all that I can find. After reading all I can find on this, I will read some words of wisdom from General George S. Patton about how to deal with hords of evil vermine and then return to the field for the final victory. I'll be back.

Slighthaze, thanks for all your help. This is much appreciated.

wjs