Obscure C/R disables Click event !!!!

[wilfranz]

This one had me really pulling my hair out for a while, until I found and corrected this really weeeeird behavior. Thought I would pass it along. (Disclaimer-- I'm an intermediate newbie, and maybe all you experienced vets already know this.)

In a 4-button CommandGroup, the #3 button became totally unresponsive. (No, it had not become Enabled=.f.) The responses for each button in the CMG were coded in a DO CASE of the CommandGroup Click event, with nothing at all in the Click events of the individual CMD buttons.

Solution: I found 2 blank lines (two C/R's) in the "blank" Click Event of the offending CMD button. Removing it cleared the problem, and replacing it reproduced the problem.

Can anyone tell me if this is a bug or by design?

wilfranz

 

[jimoo]

If the button was subclassed from another button, and the other button had the code inside of it, the parent code would be ignored because the inheritance was broken, even with blank lines.

Although it was only blank lines, it would stop the parent code from executing. To test this, put the blank lines back in and add DODEFAULT() afterwards to fire the parent code.


Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[wilfranz]

Thanks for your response, Jim.

I tried the demo test that you suggested, and it still didn't fire the Click command. I also tried putting the DODEFAULT() before, not after, the C/R's. Still nada.

Also, this command group is very basic, as an uncomplicated instatiation of the Base Class, to which I have not added any code at all.

Anyway, if this happens to me in the future, I'll surely know to search for invisible C/R's masquerading as "blank" code.

Best regards,

Bill

 

[AirCon]

Put this command before/after the blank lines:

This.Parent.Click()


-- AirCon --

 

[jimoo]

Interesting...

I wonder if there is something else going on in the parent class. The DODEFAULT() should have worked.

Try placing the following code in front of the DODEFAULT(). This will bring up the degugger.

SET STEP ON
DODEFAULT()

Step thru the processing and see if the parent code is being called.



Jim Osieczonek
Delta Business Group, LLC

http://www.deltabg.com

 

[Mike Lewis]

Wilfranz,

In general, the safest way to delete code from a method is not to erase all the characters in the method itself. Instead, find the method in the properties list, right-click on it, and select Reset to Default.

That will guarantee to get rid of CRs, tabs or other white space that causes the problems you saw. (But, take care. Reset to Default is not undo-able.)

Mike


Mike Lewis
Edinburgh, Scotland

My Visual Foxpro web site:

http://www.ml-consult.demon.co.uk

My Crystal Reports web site:

http://www.ml-crystal.com

 

[craigsboyd]

wilfranz,

Thank you for taking the time to post this problem. I was not aware that a carriage-return/linefeed would cause the code in the CommandGroup's click event to stop firing. It is good in a way that VFP is this picky, but then in some other respects I can see how it would be a bit of a pain.

DODEFAULT() is not working because "Executes, from within a subclass, the parent class event or method of the same name" and while the Commandgroup is the PARENT it is not the PARENT CLASS of the command buttons contained inside the commandgroup. The command buttons are not a subclass of the commandgroup class, but of the commandbutton.

[sub]craig1442@mchsi.com[/sub][sup]

"Whom computers would destroy, they must first drive mad." - Anon​

[/sup]

 

[teresas]

wilfranz, MikeLewis, and others,

In case this is helpful to anyone, I'll mention that my preferred way to erase all code from a method (including blank lines or whatever) is to:

make sure the insertion point is in the method's code window
press Ctrl+A (Select All)
press the Delete key

Teresa

 

[wilfranz]

Hi Teresa,

I just spontaneously realized the same method a couple of days ago while doing some ordinary stuff. And it has now also become my standard way of deleting code.

Great minds... and all that !!!

Bill