Is anyone else seeing odd problems with controls?

[Cory]

While developing a couple of macros recently that use controls I’ve seen some odd behavior. An example might be a macro that one minute works with a certain control stops working like a Wait for Control that times out when the button is clearly visible to the user. Or a command to click on a control that fails because the apparently visible control can’t be found by ME.

 

I have suspicions that it might be isolated to Vista but I haven’t been able to nail down the reproducibility to do any meaningful tests. I’ve tried several things but there doesn’t seem to be any pattern yet and things come and go in odd ways. I should have a little more time to play with this in the next couple of days but I thought I would just toss the question out there to see if anyone has noticed any problems using controls and if so what OS are they running. At this point my gut gives me about a 75% chance that it’s something I’m doing and not a bug but if no one else seems to be having problems then I can focus my efforts on possible user error causes.

[jason]

Hi Cory,

 

Are you running a 32-bit or 64-bit version of Vista?

[Cory]

32

[Cory]

I wrote a quick test macro that opened and close a few dialog boxes as quick as can be with 8 controls in a loop and let it run 93 times in IrfanView. These boxes were the same ones I was having trouble with before. It never failed. I can't figure it out. Even when it was failing before I would copy the control commands to another macro and they would work. And the failures happened in as few as 20 itterations. I don't know what to try next. Hmmm....

[Cory]

At the moment I can’t think of any way to make this rear its ugly head so I’m stumped. So my tactic now is to go back to my macros and redo them and wait for it to fail again. My question is if it does fail what can I do to figure out what’s going on? I found an application called WinID that will give me the handles but that wouldn’t tell me what ME thinks the handle is or should be. Is there any way I can peek under the veil?

[joe]

I'm afraid that I cannot be much help here. I am sure you are not using the "text" option for Controls, so that shoots that solution down.

 

At first I didn't think it was possible, but it is beginning to look more and more like there is a difference between XP and Vista Windows Control reporting, but what the heck could it be? And why would it be? Also, one would think that the error would occur every time and not just after a period of time.

 

Sounds like some sort of cache problem, doesn't it? have you tried unchecking the internal Macro Express cache and along with it, the Window Activation Caching under Options->Preferences->Caching?

[Cory]

I have not tried disabling the cache but I’m willing to try. However since I can’t get reproducibility I can’t test it. My main thing now is that I want to set some traps so when it does happen again I can gather some meaningful information to see what’s going wrong. For instance if the desired control pops up in front of me and ME errors out erroneously telling me that the control didn’t appear in the time specified time I can figure out why it’s not seeing what is obviously the desired control. In this case I can use WinID to get the HWND (Handle) of the visible control and if by some magic I could view the handle cache in ME’s brain I could tell if there’s a difference. Obviously there must be and we can figure out why.

 

You see this is the way my brain works when troubleshooting. Understand how something works and evaluate all the relevant data and see where it’s getting it wrong. The problem in the computer world is that most of the time we’re not given the complete story on how something works and definitely not given the tools to collect the data. The reason of course is that the Engineers should be doing this, not the users, but the problem in cases like these is that the user can’t demonstrate the failure the Engineer has nothing to chew on.

[patrickbarrett]

Sorry if this was already covered (I think we spoke in another post awhile back), but if not, hope this helps...

 

From my experience with Controls and different programs, I'm guessing that the Control is actually changing. The only way to verify is to open the program and do a GetControl and note the Control Details. Then run the macro (which from the sounds of it, will fail) and then do what you've normally been doing. Go in and do another GetControl and I'm willing to bet that one of the Indexes changed in the Control Details.

 

For example, the first might be 8 5 1 1 4 4 and the second might be 8 5 2 1 4 4. It's easy to over look. I believe this to be because of cached forms, indexes and such (all depends on the program I guess).

 

I've run in to this on multiple applications, where it works one time, but not another. That's how I found this little change... I've found that the 2nd or 3rd Index (checking via the "Display Control Info") will either be a 1, 2 or 3 (again, depends on the program), so sometimes it works and others it doesn't if you're just using the one GetControl.

 

To get around this I will create the first GetControl. Every time it errors out, stop doing everying and go in to the Macro and duplicated the GetControl line. Then re-capture the new/different Control in this duplicated GetControl. At this point add in an "If NOT Control Enabled" and "End If", so the order would be (this can be done over and over if it fails on occasion):

 

Get Control C1 (1)

If NOT Control C1 Enabled

Get Control C1 (2)

End If

If NOT Control C1 Enabled

Get Control C1 (3)

End If

If NOT Control C1 Enabled

Get Control C1 (etc...)

End If

 

Note, if you find the pattern the program you are working with uses, you can just duplicate the GetControl lines and then go in to the direct editor and edit the Index that seems to be changing.

 

<GETCONTROL2P:01:WJVIEW.EXE:WFC.Window.8- Default Work Order005:5WFC.Window.81WFC.Window.81WFC.Window.841WFC.Window.81WFC.EDIT>

<IFCONTROL:06:01>
<GETCONTROL2P:01:WJVIEW.EXE:WFC.Window.8- Default Work Order005:5WFC.Window.82WFC.Window.81WFC.Window.841WFC.Window.81WFC.EDIT>
<ENDIF>

<IFCONTROL:06:01>
<GETCONTROL2P:01:WJVIEW.EXE:WFC.Window.8- Default Work Order005:5WFC.Window.83WFC.Window.81WFC.Window.841WFC.Window.81WFC.EDIT>
<ENDIF>

 

I've used this method for 5 or 6 different programs and I no longer have issues with it not finding the controls "some times" and it working fine the rest.

 

Hope that helps!

[stevecasper]

This sounds a lot like a problem I've been having with Controls. Why would the control change, though, when nothing

about the program has? Sometimes it's just a new day.

 

It's tremendously irritating, but if it's not a ME problem, then it's a computer problem, in which case, it's a common

computer issue. I've had these problems happen on IE 6.x controls, Access database controls, and a few others. I have

had it happen on computers running XP Professional and Vista 32. We'll see if it happens on a Vista 64 soon enough.

 

Other than the work-around presented by having a string of "If/Thens", is there any other way that anybody can think of

to prevent or anticipate this problem?

 

Just for reference, this is the code that brought me into the forum today. The top one with 004:20 works today, the bottom

one with 004:19 worked for me the other day but no longer - if I manually change the 19 to 20, it works again, so I'm

certain that is the offending bit of code... Can anybody with more practical programming knowledge explain to me

what that particular bit of information is, so that I can understand what the difference is, and what may be causing the

change?:

 

<GETCONTROL2P:01:MSACCESS.EXE:OMainMicrosoft Access - JacksonYP09 : Database (Access 2000 file format) - [Listings]004:20MDIClient1OForm22OGrid2OKttbx>
<GETCONTROL2P:01:MSACCESS.EXE:OMainMicrosoft Access - JacksonYP09 : Database (Access 2000 file format) - [Listings]004:19MDIClient1OForm22OGrid2OKttbx>

[paul]

The problem of a changed index for an existing control is as old as the hills! For example, I wrote a macro several years ago to expand the "Microsoft SQL Server" tree in Enterprise Manager. But it wouldn't work reliably simply because from one execution to the next I was unable to predict what index might be used. The solution described by PatrickB above looks as if it might be very useful for this kind of scenario.