Help with focus

[TulsaMurph]

(Originally posted in General coding thread)
I have used FP 2.6 for most of my programming and am now working on converting to VFP. I have created a formset with two forms. On one form, a command button runs a previously written program with some @...Get lines I am trying to replace with new programming. On the second form, I have the necessary text boxes and so forth, but how do I get the running program to focus on the second form? Currently, I start my second form as invisible, then in code, change it to visible, which makes the form appear but does not gather info from it. If I use DO Form, it seems to stop the program, but the form is not accessible. I have tried both mode 1 and 0 but I am missing something. I have also been able to accomplish the same thing using several different forms and calling each one with DO FORM, but would like to avoid creating a new form for each question/answer.
Thanks for the help!

 

[TulsaMurph]

Thank you for the post Mike. That works, but each time I issue "DO FORM" I open another instance of the form. I want to keep two forms open, one visible and one that appears and hides. On the dissappearing form, I thought I would have several questions and corresponding answer boxes that are invisible until called upon by the calling program. As I understand it, the form has to be open to alter the properties of a given field on the form. I can do all of that, but don't know how to make the calling program stop and wait for the value from the form once it becomes visible. If I close the form each time I have retrieved values from it, the fields go back to default values, so on the next DO FORM, I would not get the desired effect. Am I going about this all wrong? I need a method of collecting data from the user, processing that data, then collecting more data and processing it. I could do the same thing on a single form if I could get the calling program to stop and wait for a value from a text box. Thanks again!

 

[TamarGranor]

For what you describe, it sounds like a wizard-type interface might be good. That is, the sort of thing you get when you install software, where you enter some data and click Next and the next logical page appears.

I'm pretty sure Doug Hennig wrote an article in FoxTalk about classes for wizard forms. I know he's published those classes with other articles.

Tamar

 

[TulsaMurph]

Thanks for the posts! So far, I have been able to accomplish a lot of what I was trying to do by first establishing variables (memvar=" ") in the calling program then using the DO FORM command. In the form, the first set of boxes are visible and all others are invisible. When the first command button is pressed, the varibles are updated (memvar=thisform.text1.value) and control reverts to the calling program. Once there, the first set of boxes are switched to visible=.F. and the next set are switched to visible=.T.. At the appropriate time, I use the form.show command to bring the form back to the forefront for the next round of info gathering. For some reason, I was not able to do that at first, I think I had some problems calling out the proper variables, maybe using overlapping commands, I am not really sure what is different, but I have been able to get pretty consistent results today. I still have one program that locks up FoxPro when the form is accessed a second time, and I have not figured out why. The same form works when called from a different, simpler program, so I think it must be in my programming somewhere, not in the forms themselves. I think the page frames would work great as well, and I have another project I may try them on when I get this one figured out.

Thanks for the help!
John

 

[TulsaMurph]

Thanks for the posts! So far, I have been able to accomplish a lot of what I was trying to do by first establishing variables (memvar=" ") in the calling program then using the DO FORM command. In the form, the first set of boxes are visible and all others are invisible. When the first command button is pressed, the varibles are updated (memvar=thisform.text1.value), the thisform.hide command is used, and control reverts to the calling program. Once there, the first set of boxes are switched to visible=.F. and the next set are switched to visible=.T.. At the appropriate time, I use the form.show command to bring the form back to the forefront for the next round of info gathering. For some reason, I was not able to do that at first, I think I had some problems calling out the proper variables, maybe using overlapping commands, I am not really sure what is different, but I have been able to get pretty consistent results today. I still have one program that locks up FoxPro when the form is accessed a second time, and I have not figured out why. The same form works when called from a different, simpler program, so I think it must be in my programming somewhere, not in the forms themselves. I think the page frames would work great as well, and I have another project I may try them on when I get this one figured out.

Thanks for the help!
John

 

[TulsaMurph]

Sorry for the double post, I don't know how to edit a post once it has been posted.

 

[TulsaMurph]

Thanks Mike, I'll look into it. Any keywords in particular I should look up other than "Parameter object"? In the simple environment I am using this program, I don't think it will be a problem, of course, the program I am running is locking up, so all is not well yet. I would like to know the best way to do the job, so this is a good time to learn. Thanks for the replies!

 

[TulsaMurph]

Thanks for the posts, I will work on my programming skills to bring my language up to date, I appreciate the help. I did find the line that was locking up the program by eliminating most of the program, then bringing back chunks until I found the lockup. The line that killed me was:

@06,40 GET mSOCNO DISABLE
WAIT " " TIMEOUT 2

I have no idea why it would allow me to use multiple forms, but not to hide and show one form. I replaced that line with WAIT WINDOW mSOCNO... and for whatever reason, it works now.

On to updating other programs!

Thanks again,
John

 

[TulsaMurph]

Yes, the @...get and @...say commands seem to be pretty much in the past, but they served us well. I pretty much created the programs I needed and didn't program any more until my 2.5 would no longer work with the computer I have. It was a choice between putting up with limited RAM and re-learning programming, just a matter of time. I got a lot of the old stuff to work, and created some simple new programs, but the more involved ones (still pretty simple by most standards) were put on the back burner until I had some time to figure out the new methods. Once I started learning how to use the new code, it is pretty neat, probably a lot more useful for other apps, but it really is almost starting over.

 

[TulsaMurph]

Mike, I have another question. I can not seem to get the SelectOnEntry function to work. I have tried formatting my text box as a character type with the fomat K and in programming, SelectOnEntry=.T., but when focus changes to the box either by using tab, clicking or taborder, the whole box is not selected as it used to be with a Function"K". I tried the builder, but all it does is set the format to K. Any ideas?

 

[foxdbs]

>> That works, but each time I issue "DO FORM" I open another instance of the form. I want to keep two forms open, one visible and one that appears and hides.
-------------------
The form created with DO FORM is an object, which has its object reference (variable of type Object). Through this variable you can manipulate the form and all its controls. Good syntax is DO FORM xxx NAME loxxx LINKED, then you are sure, that object reference is loxxx.
loxxx.Hide() hides the form, loxxx.Show() displays the form (alternatively you can set loxxx.Visible=.F./.T., but maybe .Hide()/.Show() are better).

loxxx can be f.e. local variable - declare it with LOCAL loxxx command first. Or you can use property of an other object, which will life all time you manipulate the form. Typically you have an central application object:
PUBLIC oApp
oApp = NewObject( 'oApp', 'oApp.prg' )
in oApp.prg:
DEFINE CLASS oApp AS Custom
oForm1 = NULL
ENDDEFINE
and you will call the form:
DO FORM xxx NAME oApp.oForm1 LINKED
and manipulate it
oApp.oForm1.Show(),
oApp.oForm1.txtName.Enabled=.T.
and so on. Thats from outside. From inside (from code of the form) you manipulate it easy with THISFORM.Show()....

Alternatively you can have forms as classes in vcx file (lot of forms in one file). Then use:
loxxx = NewObject( 'xxx', 'myforms.vcx' )
or
oApp.oForm1 = NewObject( 'xxx', 'myforms.vcx' )
so the syntax is exactly same as for all other objects and DO FORM command is no longer necessary.

Good idea is to create classes "between" baseclass and the final object for all objects:
form(=baseclass) -> pattern_for_all_forms -> final_form
If you will then program something in the pattern.. class, this will affect all forms of your application(s). - see DODEFAULT command too!

 

[TulsaMurph]

Thanks for all the help, I have some new programming to do, so I can practice some of this.

I found the problem with the SelectOnEntry, I am using FP 5.0 and there is apparently a bug Microsoft is aware of. here is the workaround if anyone else is reading this.

In the GotFocus event, paste:
IF LEN(ALLTRIM(THIS.VALUE)) = 1 && Use This.Value works for
* textboxes,
KEYBOARD '{shift + home}' && and This.DisplayValue for
* Comboboxes.
KEYBOARD '{shift + rightarrow}'
ENDIF

per Microsoft article 171983.

Hope this helps someone.
John