Re: Trying to avoid a maintenance nightmare...
- I'm not sure that I've really solved anything relative to the problem
of waiting. I finally gave up and put in a sleep after a button
push...I could not find a way to dependably wait until the
functionality behind the button push completed and returned control
(all the button was doing was clearing out a bunch of fields on a
Until that point I'd had success using a local function (that I
wrote) that issues the following calls:
I invoke this subroutine whenever I perform an operation that hands
control to the gui. But since the button episode, I'm starting to
wonder if I haven't duped myself - that all of the function call
overhead and delay isn't doing the equivalent of a sleep!!!
Relative to the labels...
What you're saying makes sense.
(NOTE: I'm not very experienced in the win32 space - much more of an
old unix guy.)
The labels do NOT show up in winspy. In the forms developer
associated with the application, the label and input field (or
dropdown, etc) are "one" control that you drop on a form - the label
being an "attribute" of sorts of the control that you fill in - which
in my ignorance led me to believe there would be a discernable
relationship within the win32 hierarchy. Note also that in this
application, the label can act as a link to drill into an underlying
object. If the label is red in color and underlined, you can mouse
click on the label and it will bring up another form (example: click
on a employee name field and it will pop up the full employee record).
So if I continue down the guitest path, I'm going to have to teach
the perl program how to click on the links.
I'm very concerned about the reliability aspect - especially given
that I would be trying to measure service levels (ie. SLA's)! And I
was really hoping to avoid having to change the perl program
everytime a develop adds a field to a form.
Relative to the control ID's:
In this case, the control ID's certainly appear to be unique on a
given form. So that may be my best option for identifying
fields...but it certainly doesn't live up to uninformed expectations.
I'm very curious how the HP and Mercury products would handle this
application. I'm pretty sure that BMC's (PETE) product strictly
records screen coordinates.
I look for forward to reading the link you posted...
--- In firstname.lastname@example.org, "Piotr Kaluski" <pkaluski@p...>
> Well, well.
> An interesting e-mail.
> > now if I can just
> > understand how to use it without creating a maintenance
> A very reasonable concern. Test scripts dealing with many controls
> really prone to become difficult to maintain.did
> > I have an old CRM Win32 application that I'm trying to build
> > against. So far I can login, use a menu to open a search form,
> > lookup a particular case/ticket, and open the located ticket. I
> > struggle quite a lot with finding the right combination of waitlike
> > commands, but so far so good.
> You mean you managed to find a way of smart waiting until a
> transaction ends? I find it a headache in gui testing, so I would
> to hear how did you solve it.ticket
> > Using winspy, I can see all of the fields/control on the
> > form...but was disappointed to see that the field labels don'tshow
> > up. I as hoping to use the labels to locate and navigate totext
> > particular controls.
> Static labels are controls by themselves. If your form contains a
> field with a label describing it, then the label and edit field areWin32
> separate controls. There is no direct link between them (on the
> level). Therefore it would be difficult to use labels for navigationthe
> between editable controls. Can you see those labels in Winspy?
> > The control id's appear
> > to be unique (for this app) within a form. But I suspect that if
> > form is changed (new field, etc), the control id's might bereordered
> > or changed.and
> It is probably a good programming practice to keep all control ids
> different, but it is not a requirement. It happens pretty often to
> find a window which has many children with the same control id (most
> commonly this id is "0").
> > I really want to avoid creating something that is unreliable
> > vulnerable to even slight form changes.try
> > What are my alternatives for creating a manageable solution?
> > Why don't the labels show up (no doubt my ignorance about
> > controls)?
> I was trying to develop a solution for it. If you have some time,
> reading this:
> If you find it interesting, let me know.