Weird behaviour - listbox 'burns' transparent hole in page in front 2

[205xld]

This is tough to describe...

I've got 2 listboxes in a container on page 2 of a pageframe on a form.

The form works in 2 modes - view and edit. When you start running the screen in view mode you just see page 1 with a textbox and label on it - no problems. Then when you switch mode the background of the page becomes transparent exactly where the listboxes are on page2. The textbox itself is not affected, but the label is truncated where it meets the edge of the transparent area. (I can send a screenshot to anyone if that helps!)

BACKGROUND INFO:

When switching to edit mode I'm making the form modal using:

thisform.Hide()
thisform.Show(1)
thisform.Show(2)

and back to view mode with:

thisform.Hide()

I'm using the same edit and view modes, pageframe, and container with listboxes, on 3 other forms without getting this behaviour on any of them!

So far I've tried messing around with lockscreen, refresh, paint and CLS. The only thing that fixes the problem is setting the visible property of the listboxes to .F. in the form's init(). Unfortunately, when you try to programmatically set and reset the visible property as required, the problem comes back after the first "visible = .T." and doesn't go away again when the program reaches a "visible = .F.

 

[alvechurchdata]

Start with the obvious question. Are you sure that the listboxes are indeed on Page1 of the pageframe? It's very easy to drop a control on the form rather than dropping it into the pageframe control.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[205xld]

To clarify, the listboxes are definitely on Page2, and the problem occurs when looking at page1. It's not a question of being able to see the listboxes in front of anything, it's being able to see ALL THE WAY THROUGH the form to the screen behind it in the area where the listboxes are.

The transparency is not 'live' though, it's a snapshot which then moves with the form. If you click on another page (other than page 1) then back to page 1, the effect disappears. Unfortunately, this only works if you do it manually using the mouse (I tried programmatically calling the click methods as a quick fix, but that didn't work)

 

[Mike Lewis]

At first glance, this sounds like a Lockscreen problem. Are you sure that the form's Locksreen property is correctly being set back to .F.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[205xld]

The last few lines of code before the probelm are:

thisform.setbuttons()
thisform.LockScreen = .F.
thisform.Refresh()
thisform.xstdtools.setmodeless()

(the setmodeless() methods being as described above). One more bit of info - if I move the 'refresh()' to BEFORE the 'lockscreen = .F.', the actual listboxes show through, rather than the screen behind the form.

 

[TamarGranor]

I can't help but wonder whether the problems you're having have to do with trying to change a form from modal to modeless and vice versa while it's running. That's generally considered a bad idea. In fact, I'm surprised it's working at all.

What are you really trying to do here?

Tamar

 

[alvechurchdata]

To clarify, the listboxes are definitely on Page2

Sorry about that - but I had to ask.

Do you get the same problem on another PC? I've not seen this particular effect but I have seen places where Fox is sensitive to screen drivers.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[205xld]

Oh dear, I don't like the sound of ("I'm surprised it's working at all")!

I have a Desktop with buttons to open different forms. Each form allows view/add/edit of different system objects (e.g. 'consumer', 'job', etc). I want the user to be able to open several forms at once to view them (they are related objects), but when any form is switched to edit/add mode I want to stop the user from editing any of the other forms (that would allow a prent to be deleted whilst its child is being edited on another form!), or using the menu to shut down the form or the application as a whole. Switching to/from modal seems to work well for this, and I've had no problems - apart from this tiny one!

If this is really unsafe for some reason I can change the way the system works, but it would be quite a big job. What would have been a better way to do it please? (If you're THE Tamar Granor by the way, then it's nice talking to you - I've got one of your books!)

Lastly - the problem is not PC dependent - tried it on a colleague's laptop. Both were running XP though!

 

[Mike Lewis]

There should be no need to make the form modal in this case. Provided each form has its own data session, and provided you do the normal referential integrity checks, it should work OK.

Re deleting a parent while its child is being edited ... well, you should never allow deletion of a record that has child records, so the situation shouldn't arise. I suppose it might be a problem if you try to insert a child record while deleting its parent, but the same problem would apply if two different users were doing that, so you would have to check for it anyway.

As for stopping the user quitting the application while in edit mode, again your normal checking should handle this. When closing the app, you should attempt to close each open form in turn. When closing a form, have its QueryUnload check to see if there are any unsaved edits, and react accordingly.

What I'm trying to say is this is all normal procedure, and should work properly even the forms being edited are modeless.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[TamarGranor]

What Mike said about your app. I'm generally opposed to modal forms except for very specific short-term things (like providing printer parameters).

<<If you're THE Tamar Granor by the way,>>

You mean there might be more than one?! Yeah, I'm that Tamar Granor. Nice to meet you. Glad I've been able to help.

Tamar

 

[205xld]

OK folks - Thanks to both of you for your feedback. Shame such a small anolmaly will cause so much extra work..... c'est la vie I suppose. No more mode switching for me.