Form AlwaysOnTop = .T. but no need to be in focus 2

[torturedmind]

Hi there.

I have this requirement by some of our internal users where they need to verify some names as they type them in a text box. Combo or list boxes are not options since the partial string they're typing could be anywhere in the entirety of the name(s). So I thought of using a grid in a child form to show the possible names. The child form's AlwaysOnTop is set to .T. but should not get the focus yet unless triggered by a key or by mouse click because the user could still be typing in the text box of the parent form. But when I "DO FORM frmChild" in the InteractiveChange event of the text box in the parent form, the child form gets the focus and won't let me go back to the parent form. I reckon am doing this wrong. Anyone care to guide me to the right path? Or is there a better way to approach this?

TIA


kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."

 

[Olaf Doschke]

No, you can't do a form without moving the focus there. You shouldn't use a grid, neither as a control on the same nor on a child form, use a combobox in it's default drop-down combo box mode, then the user can type in and you can use the displayvalue as filter to the list via eg SET FILTER TO Thisform.combo1.Displayvalue $ namefield IN table.

You might also use the combination of textbox + listbox, but on the same. Why start a secondary form?

Bye, Olaf.

 

[torturedmind]

Thank you very much Olaf for the very quick response. I need to have a child form with a grid in it because if there will be a near-perfect match, the user will need to verify further by viewing other fields in the grid. The user will then put some remarks on a certain column/field (which is the only editable column, btw) and then decides whether to continue the data entry or not in the parent form.

TIA

kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."

 

[Mike Lewis]

Kilroy,

Another option for you to consider:

Instead of putting your grid in a child form, put it in a container on the main form. Make the container invisible by default. Make it visible in the text box's InteractiveChange. Make it invisible again when the user has finished the entry of the field.

You'll need to experiment a bit to get the details right, but I think the general concept should work.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, you can always also integrate more columns in the combobox or listbox and make one editable by also binding it to a textbox.

Mikes idea about a container you dynamically make is visible is a way you can choose, but I'd then not want to have such things in form at design time. I have to maintain such an app, which has perhaps 5 or more layers additional to pageframes, it's unmaintainable. Keep it simple.

Even if you stay with a seperate form, what always should work after starting the form nonmodal is finally setting the focus to the a parent form control again, eg a first try would be THIS.Setfocus() right after DO FORM. Of course your child form must not be modal, for that.

Bye, Olaf.

 

[torturedmind]

Thanks Mike and Olaf for your feedback. I tried both ideas mentioned above and I was hopeful either will surely work. But there is always the error message

Function argument value, type, or count is invalid.

whenever I issue

THISFORM.oContainer1.oGrid1.REFRESH()     [i]&& Mike's suggestion[/i]

or

oChildForm.oGrid1.REFRESH()     [i]&& original idea[/i]

I think there is no error in the REFRESH command but somewhere else. Problem is, Foxpro is not really helping me about where I should look. I'm using a form from ThemedControls as the parent form (if it matters).

TIA

kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."

 

[torturedmind]

I found out that the problem was not really the REFRESH but the command

SET FILTER TO ALLTRIM(THIS.VALUE) $ name_field

The ALLTRIM(THIS.VALUE) goes out-of-scope during the REFRESH command. I solved this by declaring a public variable in the text box's INIT event and used that variable in the SET FILTER command like so

some_var = ALLTRIM(THIS.VALUE)
SET FILTER TO some_var $ name_field

In the end, I used Mike's concept and is now working as expected.

Thank you both for taking the time. I really appreciate it.

kilroy
philippines

"Once a king, always a king. But being a knight is more than enough."

 

[Mike Lewis]

Glad to hear you've got it working, Kilroy.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

You can also do it by macro substitution, no need to use a public variable.

LOCAL some_var
some_var = CHRTRAN(ALLTRIM(THIS.VALUE),["]+chr(13)+chr(10),[]) && this also removes any " and carriage return or line feed in the entered value.
SET FILTER TO "&some_var" $ name_field

This is then substituted at the moment you set the filter, SET("FILTER") will then be the litaral expression, eg if the user typed in [value] in the textbox: "value" $ name_field.

In filter exression you can only rely on field names, of course public variables are possible, but if you do this at several places for several filters of several aliases, that'll cause side effects of course.

The thought about scopless code is always important with any FILTER. FILTER conditions are evaulated, whenever and WHEREever the alias is accessed, eg by the grid, when you do a REFRESH. So the only scopes here are the alias and the datasession and of course you can access anything public, eg _SCREEN, but you better not use that.

Also ON KEY and other ON commands define the code to run, when an event occurs. And that does NOT run in the context of object defining it, that must always be taken into account.

Bye, Olaf.