MyEditor (Edit Control) Validation in VFP-9: STOPPING Menus, etc?

I'm trying to *stay within myEdit control(s)* until *pProcessing* is finished. I seek *better ways*, per se, from any of you (besides making the form(s) modal). Here are some of my awkward (non-bulletproof) workarounds.

In myEditor.VALID ...
If pProcessing
This.SetFocus
* Return .F.
Endif

To STOP Menus...
In _msysmenu: set skip for pProcessing (for every menu bar()... )
OR
SET SYSMENU SAVE
SET SYSMENU TO
...when pProcessing is finished
SET SYSMENU TO DEFAULT
(I'd prefer to make _MSYSMENU/SYSMENU just *freeze* ... in a modal (myForm.windowtype=1) manner and not have it *blink* off and on )

To prevent oApp.oToolbar...
If pProcessing
oApp.oToolbar.enabled=.F.
Endif

Hiding forms until pProcessing is completed, Etc. Etc.

Thanks in advance for any thoughtful workarounds and/or feedback

Visual FoxPro2

Philip,

So exactly why are you wanting to create this pseudo-modal mode of a form without just using a modal form

Thank you for your response, David.

Modal Forms seem (for me) often problematic:
1) Formset forms (calling one form's methods from the other)
2) Modal forms ...seem not to allow seperate menus.
3) Keystroking gets a little excessive to release modal forms, especially when they are *oft-called* (...repeatedly hitting even the <enter> key gets cumbersome)
4) Calling forms (eg. auto-text forms) FROM modal forms seems especially tricky and limited.

Philip,

This one form is a real special case form right So I'm not sure the overall aversion to modal forms applies.

>1) Formset forms (calling one form's methods from the other)

I don't know that many people that use formsets, they were a holdover of 2.x style forms. The fact that you could not mix and match modeless and modal forms in a set really made them have limited functionality.

>2) Modal forms ...seem not to allow seperate menus.

You talk about going to great lengths to disable the menu so why is this a problem in this case

>3) Keystroking gets a little excessive to release modal forms, especially when they are *oft-called* (...repeatedly hitting even the <enter> key gets cumbersome)

I really don't understand this, modal forms close the same ways modeless ones do, a click of an Ok or Cancel button or clicking the X button in the titlebar.

>4) Calling forms (eg. auto-text forms) FROM modal forms seems especially tricky and limited.

I'm not sure what you mean by auto-text forms. If you launch a modal form from a modeless one the new form works as it is expected it is modal. Conversely though if you launch a modeless form from a modal form the modeless form is modal.

Thank you (again) for your timely and thoughtful refutations David, ... I'll focus on the "special case form" #4 a bit (if thats OK)...

I've written MyAutoTextListForm that functions with a MyEditControl (class). The MyAutoTextListForm functions very similar to VFP-9 IntelliSense (IntelliSense behaves like a non-modal list-form to me). MyAutoTextListForm also functions similarly to the VFP-9AutoText property (yet another non-modal list-form it seems) of text-controls.

(Perhaps the VFP-9 AutoText property for Text-Controls is not modally affected as it probably works seamlessly with modal forms.) (I don't perceive Intellisense nor AutoText lists, without a form container)

MyAutoTextListForm is limited by my modal forms (namely mouse clicks). Through much trial and error I’ve managed some fairly tolerable workarounds where MyEditControl (class) within modal forms can respond well enough with MyAutoTextListForm.

Another thought (workaround) just hit me (after all your thoughtful refutation): I might try to make the MyAutoTextListForm a MyAutoTextLIST control within myParent.form

Thank you (again) for your timely and thoughtful refutations David, ... I'll focus on the "special case form" #4 a bit (if thats OK)...

I've written MyAutoTextListForm that functions with a MyEditControl (class). The MyAutoTextListForm functions very similar to VFP-9 IntelliSense (IntelliSense behaves like a non-modal list-form to me). MyAutoTextListForm also functions similarly to the VFP-9AutoText property (yet another non-modal list-form it seems) of text-controls.

(Perhaps the VFP-9 AutoText property for Text-Controls is not modally affected as it probably works seamlessly with modal forms.) (I don't perceive Intellisense nor AutoText lists, without a form container)

MyAutoTextListForm is limited by my modal forms (namely mouse clicks). Through much trial and error I’ve managed some fairly tolerable workarounds where MyEditControl (class) within modal forms can respond well enough with MyAutoTextListForm.

Another thought (workaround) just hit me (after all your thoughtful refutation): I might consider to make the MyAutoTextListForm a MyAutoTextLIST control within myParent.form.

Philip,

>Thank you (again) for your timely and thoughtful refutations David, ... I'll focus on the "special case form" #4 a bit (if thats OK)...

Everything is OK. *g*

>MyAutoTextListForm is limited by my modal forms (namely mouse clicks). Through much trial and error I’ve managed some fairly tolerable workarounds where MyEditControl (class) within modal forms can respond well enough with MyAutoTextListForm.

If MyAutoTextListForm is a modeless form and it's launched from a modal form, then the spawned form will be modal, ie you can't click back on the orginating modal form. That's sort of the way modal works, Windows is full of these dual modality dialogs and yes it's annoying. If your original form is modal you've already forced on the user "finish this task before you do anything else", now when you spawn your lookup form they have to make a selection there before they can get back to the other form.

Does your original form need to be modal if it were modeless you could jump back and forth between the forms without restriction.

>Another thought (workaround) just hit me (after all your thoughtful refutation): I might consider to make the MyAutoTextListForm a MyAutoTextLIST control within myParent.form.

You can either dynamically add the object at runtime to the form, or have it there all along and just toggle its .Visible property.

Let me play devil's advocate here and ask why this lookup functionality isn't just built in as part of your MyEditControl class

David asked: "Does your original form need to be modal if it were modeless you could jump back and forth between the forms without restriction."

Philip responds: Yes, many of the forms using the MyEditControl class MUST be modal (as they behave like messageboxes).

Philip stated: “Another thought (workaround) just hit me (after all your thoughtful refutation): I might consider to make the MyAutoTextListForm a MyAutoTextLIST control within myParent.form.”

David responded: You can either dynamically add the object at runtime to the form, or have it there all along and just toggle its .Visible property. … Let me play devil's advocate here and ask why this lookup functionality isn't just built in as part of your MyEditControl class

Philip responds: I tested the ‘toggle’ version (visible property) of MyAutoTextLIST (over the weekend) … with some success:

Form modality no longer prevents MyAutoTextLIST (class) characteristics.

I had to add the following code to a *listappear* method

pllo=_screen.ActiveForm.lstPhrases1

ON KEY LABEL LEFTMOUSE KEYBOARD IIF(MCOL(0,3)<pllo.left or MCOL(0,3)>pllo.left+pllo.width or MROW(0,3)<pllo.top or MROW(0,3)>pllo.top+pllo.Height,'{ESC}',"")

Display speed has increased .. also list resizing and select speed has increased

But an SQL problem has occurred which I have yet to resolve:

lCategoryNo=Val(Getwordnum(This.ctextkey, 2, '=' ))

SELECT DISTINCT myPhrase From 'data\Phrase' Where Category = lCategoryNo Order By Phrase Into Cursor tempPhrase Readwrite

…

Select tempPhrase

Set Filter To Phrase=pSearchString

…

thisform. MyAutoTextLIST1.RowSourceType = 2

thisform. MyAutoTextLIST1.RowSource ="tempPhrase"

Seems that the public filter (or something) on the cursor causes error: “Cannot access the selected table.”

If I can’t workaround this error, I’ll test your lookup functionality … built in as part of … MyEditControl class …Assuming I can create methods to create the listobject (based on the MyAutoTextLIST (class) and release/destroy it … etc.

Philip,

Is there an index on Category in Phrase That will help speed up the SQL. Also rather than using a filter why don't you just add Phrase = pSearchString to the where clause If MyAutoTextList1 was setup with it's RowSource and RowSourceType before the above code all you'd have to do is call its Requery() method to tell it to reread the RowSource.

David, thank you for your thoughtful responses.

I've thoroughly tested your suggestions and continue to get the error:
"Cannot access the selected table. tempPhrase"
...during some form (and modal form) calling. (The MyEditor (autotext) control class is placed in class-hierchial forms, (about 7-10 forms total) and several times per form.)

I also redundantly tested "this.requery" and "CREATE CURSOR tempPhrase (Phrase C(150), Special C(150))" in numerous additional lines with no resolution at this time...(Note the '150' field width)

BUT everything *works* when I use a TABLE instead of a CURSOR, (only I have exclusivity violations with other app-instances, LAN, etc.) ... i.e.:

SELECT Distinct Phrase,Special From Phrase Where Category = lCategoryNo Order By Phrase Into TABLE tempPhrase

*Of course the Init Code:
If !used("tempPhrase")
use tempPhrase in 0 shared
Endif
*...etc.

David, I think I'll try to get this SQL...TABLE working at this point (with the Rushmore and all). The CURSOR-Alias seemed ideal though. Albeit, I'm willing to post *ALL-my-disjointed-code* with you (here) if that's expedient (about 7-10 pages) for you (and/or you-all) to decipher.

Philip,

Debugging an app of that size is sort of out of scope for free peer-to-peer support.

I will tell you though that a long time ago I settled on using an array property and a couple of custom methods on my cbo and lst classes. They get RowSourced to this.maList and RowSourceTyped to Array. The methods handle the population of the array. For the most part they populate the array when the object instantiates. I've just found that this was the most stable and error free way of using these two objects.

Can you boil it down to a smaller code fragment that throws the error If you step through the code in the de**** which line(s) of code throw the error

Philip,

Debugging an app of that size is sort of out of scope for free peer-to-peer support....
Can you boil it down to a smaller code fragment that throws the error If you step through the code in the de**** which line(s) of code throw the error

David,

The problem is resolved this a.m.; I reconsidered and placed "this.requery" (as you suggested before) in MyList.REFRESH and results are promising ... all seems well:
1) Significant speed
2) No modal form limitations
3) Multiple instances, LAN functionality, etc. of the MyEditAutoText with myList classes
4) No "Table" errors, whatsoever.

I suppose if future problems arise I'll seriously consider the array route you just suggested. Thank you again for sticking it out with me

Philip,

You are welcome. I'm glad you got it working.