Question with MSCOMCT2.OCX - (refreshes automatically?)

[Goofus828]

Hi all!

I have a question about MSComCt2.Ocx.
I am using the calendar on my main form.
I was recently sitting on a form that is 2 levels deep from the main form when all of a sudden my error handler kicks in stating that the SELCHANGE() method fired!

The error was Error #3 'file in use' when that file is not being used at all at this time.

Does anyone know if this control has an automatic refresh built in that checks for any changes to its CONTROLSOURCE that I assume would call the SELCHANGE?

I'm using VFP 9.0sp2.

Thanks!
Josh

 

[Dan Freeman]

A lot of things can cause Foxpro to fire a refresh. Moving the record pointer is usually the culprit. (Note that it sometimes happens beyond your control.)

The real question is why that table isn't open if it's one of your control's controlsource? It's kind of a "rules of the road" thing that if you use a file as controlsource it has to stay open.

The 'file in use' error could come about if the file is opened exclusively in one datasession and something tries to open it again in another. But, again, if it's a controlsource why wouldn't it already be open?

 

[Mike Lewis]

Josh,

I can't add anything to what Dan has said. However, it would be useful if you tell us which control you are using. You mentioned MSComCt2.Ocx, but that's not a control; it's a container that holds a number of different controls.

Also, you say the error handler kicked in "all of a sudden". That suggests the error arose without anything to trigger it. What exactly was happening when at that point? For example, did you look at the calling stack to see what methods were executing?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Goofus828]

Mike, I am using MSComCtl2.MonthView.2 according to the OleClass in the Other Tab of the properties window.

Dan, the control source of this calendar is a variable not a table.

The weird part is when it error handler fires, it reports an alias name that is in a totally different part of the code that has never been executed.

The call stack is as follows ( simplified )
1) main.exe
2) MainForm.cmdUpdate.Click
3) pUpdate() in Main.exe
4) PatData.cmdNote.Click ( form called PatData, now I'm sitting in an editbox, just waiting )
5) MainForm.calShr.SelChange ( the mainform's calendar has fired )
6) MainForm.Refresh ( called in the MainForm.calShr.SelChange )

Now, I have not done anything at all. I'm still sitting in the EditBox, waiting. The ControlSource of the MainForm.CalShr, which is a variable, is not used in the PatData form at all.


I appreciate the feedback, but I'm stumped.

Thanks.

 

[Mike Lewis]

If you know the name of the file that the error refers to, you could try setting a breakpoint on USED("xxxx"), where xxxx is the filename in question.

Just a thought.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[DSummZZZ]

So I take it you have no timers firing either?

Maybe put a breakpoint in your SELCHANGE event. Even if it's just on a RETURN statement, just to see what's going on. Maybe get a clue to what fired it by looking at the stack at that point.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Dan Freeman]

What's in the Error() method of the OLEControl?

You mention an error handler, which makes me assume an ON ERROR routine. If that's not the case, ignore this.

If the error is really originating in the OLEControl, that control's error() method would be the first thing called if there's anything in it. Even if it's just SUSPEND, put something in it and see if it gets called.

When you have a weird, hard to understand error like this, sometimes it's worth spending a little time to make sure you have the right origin. You'll sometimes find you're spinning your wheels chasing an error that's caused elsewhere but reported where you're looking.

 

[Goofus828]

Dan and Mike,
This is what I found out.
I created a simple project with one form and put the MSComCtl2.MonthView.2 calendar control on that form. In the SelChange() of the calendar I put in a simple StrToFile() of the date & time and the call stack.

It appears that every 2 minutes the SelChange() is executed. I cannot find any property that would indicate an "Interval".

Now I know what is going on.

I appreciate your knowledge, it help me down the path to discover what is going on.

 

[Mike Lewis]

Josh,

Your analysis seems to be correct. I just created a simple form with nothing on it but the control on question, and I can see the same behaviour that you are seeing.

I also found a few threads in other forums where the same behaviour was reported. For example:

http://www.vbmonster.com/Uwe/Forum.aspx/vb-bugs/498/MonthView-control-bug

If you can't find a simpler workaround, the only thing I can suggest is that you use a different calendar control, such as the Microsoft DTPicker.2 control, which looks the same as the Monthview but doesn't have a SelChange event. There are also many third-party calendar controls floating around, or you can construct your own using native VFP controls.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

Good sleuthing!