Restriction of mouse movement in a Form 3

[SitesMasstec]

Hello colleagues!

I have a Form which has a Container, with some objects.

The Container is not Visible, until the user right click in Page1 or ...Page5, then the Container becomes Visible:

In Page1...Page5, RightClick, I have the code:

this.Parent.Parent.cntRepetir.Visible= .T.
this.Parent.Parent.cntRepetir.cboOndeRepetir.SetFocus

It works well, if the user, after choosing an option in the ComboBox, clicks on button OK or Cancelar.

But I realized that the user can point the mouse to any other area of the Form! I want he/she must click on OK or Cancelar button.

Is it possible to limit the mouse movement only inside of the Container till the user click on OK or Cancelar button?


Thank you,
SitesMasstec

 

[mJindrova]

Hi,

Simply? Use a modal form.





mJindrova

 

[Mike Lewis]

I don't know any way of preventing the user from moving the mouse outside a given area. Not even a modal form would do that. The best you can do is to prevent the user from clicking outside the area. But that would just be a matter of not responding to Click events in any of the relevant controls.

Perhaps I have misunderstood what you are trying to achieve.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I second mJindrova,

a modal form with the content of your container doesn't restrict mouse movement, but the user has to interact in a modal form and close it, before anything else in your application xcan be used again. This is a basic way of enforcing usage of controls.

The other thing you could do is set all other controls disabled.

The plan to limit mousemoves is not even remotely a good idea, users have to be able to use other applications at any time and then this would not only hinder them to use anything of your application outside the area of your container, but anything at all. That's not a feature of Windows. You have really bad ideas.

Chriss

 

[SitesMasstec]

Well, I deleted the Container in the main Form and created a new Form, which pops up when the user RightClick a Page in the Pageframe:

Now when the user clicks Cancelar I use the commands:

thisform.Release
RETURN

and the focus goes to the main Form

In the OK button, Click event in the Child Form, I have reference to some fields in the Main form, like this:

frase1="thisform[highlight #FCE94F].Parent[/highlight].Pageframe1.Page"" + NumberPax + ".paxmarit" + ".txt" + PCOMOTAXA(OT) + ".Value"

When I click OK in the Child form, a Program Error is shown: PARENT is not an object.



Thank you,
SitesMasstec

 

[Mike Lewis]

This is an easy mistake to make. [tt]thisform.Parent[/tt] is not a reference to the main form. The keyword [tt].parent[/tt] refers to the parent in the containership hierarchy, not the calling sequence.

What you need to do is to pass a reference to the main form to the child form (the one containing the OK and Cancel buttons). You can do that as follows:

1. In the calling form:

[tt]DO FORM ChildForm WITH thisform[/tt]

2. In the Init of the child form:

LPARAMETERS toCaller
THISFORM.oCaller = toCaller

where oCaller is a custom property of that form (which you would normally create a design time).

3. In the OK of the child form, you can refer to objects in the main form like this:

[tt]thisform.[highlight #FCE94F]oCaller[/highlight].Pageframe1.Page ...[/tt] etc.

Hope this makes sense.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

A new form is a new form, you have no reference to elements of the main form in the popup form, so work with storing results into a dbf or cursor you ddedicate to this interaction.

I also already told you back in thread184-1830156

why do you even fiddle with the objects?
Those other 4 controls have a controlsource, don't they? If I assume you always do the same as in your other recent thread, one record holds all the fields, all you need to sum is those four fields...

translated to this new situation: You don't actually need to store some result value back into some other textbox of the main form, what you actually need to update is a field of a table. Do that, that's existing independent of forms and controls and you can open up tables shared and act on them from multiple forms. Your convoluted programming is what makes you step on yur own feet.

Say you display tableX.FieldY in some textbox.value by controlsource. Then the code to update that textbox is just

Select tableX
REPLACE FieldY with newvalue
*o or to read something off
Store TableX.FieldY TO somevariable

And that will work, no matter if that textbox is in the same form, if you move a container into a page of a new pageframe, or even onto a separate form. The only re4quirements on the code that's moved into a new form is to also open TableX and position on the same record, and that could be done without any code, just by letting the separate form work in the same datasession as the main form, which is done by default, as a newly created form has its datasession property set to 1. So a popup form will have all the same tables open in the same workareas and can act on them, instead of acting on the main form and controls of it.

I do remember back than you said you're at a stage of prototyping without a database behind the forms, so you program that way, it just shows how rigid this way of working is and how it makes it hard to just move some container into a new separate form, your "wirings" with all the other controls on the main form are now invalid, all the code you wrote is not working anymore and needs to be rewritten. Don't do that, think about better reusable code, that's not only a topic of OOP, that's just a general idea of programming in a way that you can move something into a new form, for example, without breaking it.

Chriss

 

[SitesMasstec]

Mike, I make the changes, but when I RightClick on Page1, an error appeared: Property OCALLER is not found.

Maybe the error is because of this, which I have not understood how to implement:

where oCaller is a custom property of that form (which you would normally create a design time).

Thank you,
SitesMasstec

 

[Mike Lewis]

This is confusing.

You previously said that an error ("PARENT is not an object.") occurred when you click on the OK button in the child form. So I gave you a way to fix that. But now you are saying that an error occurs when you right-click on Page1. But Page1 is a member of the main form, not the child form. So, of course, it will fail to find the custom oCaller property, because that is a property of the child form.

In general, if you want any control on a form to reference any other control on the same form, you simply use [tt]thisform[/tt] (or sometimes [tt]this.parent.parent ...[/tt]). You do not need the custom property (oCaller in this case).

And, in any case, what has all this go to do with restricting the movement of the mouse?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SitesMasstec]

Mike: I changed the thisform.Parent.Pageframe1 ... etc (which was in a Click event Property inside the Child form) a to thisform.oClaller.Pageframe1 ... etc

I follow your advice (in the Child form and in the Main form), except that about oCaller custom property. I have never created a custom property.


Thank you,
SitesMasstec

 

[Mike Lewis]

I have never created a custom property.

OK. Let me try and talk you through this:

1. Open the form in the Form Designer (in this case, it would be the child form).

2. Select New Property (from the Form menu).

3. In the resulting dialogue, type a name for the property (in this case, oCaller).

4. Ignore the other fields in this dialogue.

5. Click Add, then click Close.

6. Save the form.

From now on, you can reference the custom property by referring to THISFORM.oCaller. You can treat this just like any other property of the form, such as THISFORM.BackColor or THISFORM.Height.

In your main form, you will call the child form like this:

[tt]DO FORM ChildForm WITH thisform[/tt]

This tells the main form to pass a parameter to the child form. In this case, the parameter is an object reference to the form itself (the main form).

In the Init of the child form, you will receive the parameter:

[tt]LPARAMETERS toCaller[/tt]

and then store it in your custom property:

[tt]THISFORM.oCaller = toCaller[/tt]

So now the oCaller property contains an object reference to the calling form (the main form). You use this property to refer to any of the properties, methods and controls on the calling form. So, for example, if you want to know the calling form's back colour, you will find it in [tt]THISFORM.oCaller.BackColor[/tt].

In this case, you want to refer to the value of a textbox control on a page in a pageframe on the main form. So you would refer to it like this:

[tt]THISFORM.oCaller.PageFrame1.Page1.text1.value[/tt]

But of course that would only work in the child form, because only the child form knows about oCaller. To reference the same value from the main form, you would do this:

THISFORM.PageFrame1.Page1.text1.value

Does this make better sense?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SitesMasstec]

Great news, my friends!

Thank you, Mike. Following the few steps you provided, I got the task accomplished!

Now, I will dive more carefully to understand these steps, as a form to call other child form and the child form to pass data or to command processing in the main form will be a common need for me, as a programmer.

Just aother good notice: last week I ordered from Amazon the book "The Visual Foxpro Report Writer: Pushing It to the Limit and Beyond" which I must read, advice from another thread.

Last, but not the least, Chris Miller also have gave me valuable and critical advices here, some of which with great detail that I have been learning, in spite of the fact about my slow step.


Thank you,
SitesMasstec

 

[Mike Lewis]

Delighted to hear that our advice has been useful, SitesMasstec.

The book you ordered is a good choice. I just wish there were more books about VFP available, especially for less-experienced developers.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SitesMasstec]

Mike,in the last two decades, I acquired 11 books about VFP, most of them published by Hentzenwerke, but none of them with a deep section about reports, of course, because VFP has many subjects to address.

On time, the title of this thread ("Restriction of mouse movement in a Form") is irrelevant now: it should be "Processing data from a form into another" or "Pop-up form over another" or maybe another but not the one I used here.

Here is the result:

Thank you,
SitesMasstec

 

[Scott24x7]

SitesMasstec,
If your fundamental question has changed, I'd suggest starting a new thread, and be clear about what you want to achieve, rather than "enforcing a solution".
From what I've seen of your posts (and I mean no offense, this is just my observation of your approach), most of the time, you're fighting against fundamental application development principles and/or VFP's events environment.

When you tell us what you are trying to achieve (much like how your discussion about your app design, which originally you were trying to treat as a 400+ field wide flat-file) we introduced parent-child relationships and data normalization, but what I'm seeing is you haven't really followed most of that. As a result, now you have problems like these in your app, and application control becomes incredibly messy, and worse, it is made messy because you're not letting VFP do what it's good at, rather you want to make it work the way you THINK the programming of your app works, rather than embracing taking a little time to learn a bit more about event-drive, object oriented development, and relational databases. In the end, it will be faster for your development of your application.

This isn't a criticism, as I mention, rather a suggestion. But please, start a new thread and tell us about the business problem you're trying to solve, and let us guide you in how VFP can do the work for you, rather than you working against how it naturally works.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS, ATD

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Piotr Czekalski]

Problem has been solved. The program works. Everyone has their own individual programming style. Have a nice day to everyone and to you Scott !

 

[SitesMasstec]

Yes, Scott, be sure I embrace and thank you for your valuable and constructive advices.

Indeed, the topic was changed, I should have started another thread, because I was trying a solution by restricting mouse movement inside a Container, but then I learned here that one solution would be to have a Child form, as Mike pointed. And Chris also presented another solution.


Thank you,
SitesMasstec