Pesky Boxes at Runtime

[Scott24x7]

Hi All,
Have recently been experiencing a very odd behavior (and thus far alway on the last tab of my pageframe). For visual direction, I use boxes (shape objects, transparent with a border), to set off various parts of the form. But on this last form, some of them though at design time are "sent to back" seem to "migrate" to the front at run time. The result is, you can TAB through fields, but you can't CLICK onto them. Is there some way to always force the box behind the object? I even selected all objects, and pasted them BACK onto the box objects and after rebuild, they were STILL behind it at run time. So annoying!

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[vgulielmus]

I believe the animated gif in your signature, finally make sense :-D
Don't know if this is the best advise, but cut the objects behind the box, and paste them again.

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Scott24x7]

Yeah, that's exactly what I did.
I had this same problem on this page a couple days ago, and that worked, but this time, they are still "behind" the boxes at runtime... :/

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[DSummZZZ]

Did you also 'Bring to front' the objects you want to click on?
I would also suggest doing a 'Send to back' one at a time.

-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Auguy]

I have had similar situations in the past. I solved it by using code to "send to back" for the object that was causing the problem. It's the z-order if I remember correctly. Never did find a solution or work around in the designer, seemed random. I did have some success with setting all of the controls in terms of back to front and then saving the form immediately. It seemed as if you mess with the controls after that the z-order gets messed up.

Auguy
Sylvania/Toledo Ohio

 

[Olaf Doschke]

In the end, if you look at the result vcx scx records of the controls should be in z-order, IIRC. And in very complex forms that can have its own life, in the way changes in a form cause deleted and new records and how they are packed. All that is from memory and not guaranteed, but you may look into the raw form data.

Bye, Olaf.

 

[Scott24x7]

Where did you put the Zorder call in Dave? I tried that in Refresh and it hung the form. :/

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Scott24x7]

Ah... Got it.

Just put This.Zorder(1) in the INIT of each of the object boxes and they are magically forced to the background at run time.
I think I'll just include it in the base class... If there's ever a time I don't want it, I'll NODEFAULT it then.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

>If there's ever a time I don't want it, I'll NODEFAULT it then.
NODEFAULT only suppresses native class code/behaviour.
To suppress anything you add into a class you suppress it by not calling dodefault.

Bye, Olaf.

 

[Scott24x7]

We had this conversation already...
* in this case suppresses anything inherited...


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

* in this case suppresses anything inherited...
But that's wrong in itself
You only suppress anything with a NODEFAULT because you don't DODEFAULT and you suppress native behaviour.
It's not the NODEFAULT supressing anything, though, that's the wrong impression.

It's sufficient you put any code in init not doing DODEFAULT() and your call of zorder doesn't run. You don't harm suppressing the default Init code, as the constructing of an object is'nt done there, but if it would, you would suppress the object creation. You don't want to suppress the native init behaviour, you only want to suppress your code.

Now if you say "but it's ny base class and NODEFAULT acts on the base class". Then notice I always talked about native base classes. You can't define such a root native base class yourself, you always have specify a base class for your classes, so NODEFAULT never acts on your own code. If you want to suppress the zorder of your base class a simpe comment or any code not calling dodefault put into the next level class or into the form.control.init will suppress your own base code.

Bye, Olaf.

 

[Scott24x7]

Mate, simply not true...
Try it in a put MESSAGEBOX("HI THERE") in the Refresh caluse of a text box base clase.

Put 2 text boxes on the form.

For box 1 Put * in the REFRESH clause
For the other do nothing.

Run the form and refresh it... you will get ONLY 1 MESSAGEBOX call, the other is entirely suppressed unless you specifically call DODEFAULT() after the * Or inteased, put in MESSAGEBOX("This is non-inherited") in that same box, and refresh.

You will see
"This is not inherited" from that box's refresh call
and
"HI THERE"
from the inherited box, but ONLY 1 time, unless you call DODEFAULT() before or after the code in the refresh.
And a simple * on it's own WILL accomplish this, I do it ALL the time.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

All you're saying is true, but you still don't understand NODEFAULT.

The things suprressing the messagebox are the comment or other code. And yes, only doing DODEFAULT calls the aprent code.

NODEFAULT nevertheles only is about the native class code, nothing more. It only suppresses ALL inherited code, because it is code preventing parent code, but not because it's NODEFAULT, any code prevents parent code. That' the point I made. You were sepcifically saying: "a time I don't want it, I'll NODEFAULT it then.", You never need to NODEFAULT your own code, you only need NODEFAULT to suppress native behaviour, no more, no less.

Take it from the help: "Prevents Visual FoxPro from performing its default event or method processing for Visual FoxPro events and methods".
No more, no less.

It's not the NODEFAULT suppressing your zorder code, it's any code, even a * comment only, which suppresses the inherited init code and overrides it, unless you also do DODEFAULT.
That's what I want to stress out to anybody coming here and again becoming a wrong impression of what NODEFAULT does.

There actually is no default behaviour of the Init() event, there only is a behaviour about it's return value, and so NODEFAULT in any INIT() has no meaning, you don't even suppress the object creation, the object and all it's methods and properties already exist when init runs and you can do further initialisation steps. So don't talk about NODEFAULTing your init for that reason alone. NODEFAULT has very limited use in Keypress and other events with some definitive native behaviour.

Bye, Olaf.

 

[Olaf Doschke]

I want to show something else on topic of the zorder method:

Here's a form with in image (partially) in front of a textbox:

And this is a browse of some record fields (I queried the class memo into a c(254) to make it readable in the browse window):

Now I change order by "send to back" of the image:

And this is the effect on the SCX raw data:

You see the order of records simply has changed. The textbox now is after the image, the uniqueids have not changed, but the records were rearranged.

In consequence the objects appear in order of the raw data of a form, the last row appears in front of everything else (if things overlap, of course). Your init code put into all your control base classes means you're inverting this behaviour, every control generated is sent to back and thus the last control is created beneath everything, the first control genrated is on top.

I believe what you said about making use of the form designers "Send to Back" or "Bring to Front" and the result behaviour as I know what did go wrong with such things in old and more complex forms in some projects, so I feel your pain, but I wouldn't go that route for it changes the default behaviour of the control instanciation to the opposite z-order wise. In general this will become a pain in the ass in all your other forms. You should really fix the one form and its record order to let controls appear in the right z-order.

Bye, Olaf.

 

[Scott24x7]

Yes, and I said the same thing... I want the native event to occur, but not the inherited code... you're talking about 2 different things, and the POINT I'm trying to make is WHEN to you NODEFAUILT, when to use DODEFAULT and when <anythinng> will do...


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

>I want the native event to occur, but not the inherited code
And for that you do NODEFAULT?

Bye, Olaf.