From: Fergal H. <fer...@gm...> - 2009-06-24 23:32:22
|
Hi Steve, In regards to the point of confusion, the object should exist so long as the data binding to the MenuBar is updated before clicking the first menu. If clicking on the first menu is what triggers the dataProvider source object to be populated then the object won't exist until that happens. Answers below for your other questions: On Thu, Jun 25, 2009 at 8:19 AM, Booth, Steve <ste...@hp...> wrote: > Hi Fergal, > > I've asked my management for approval to share what I have. I should get a > response within 2 days. > > In the meantime, I'm confused about one of your responses (I commented your > email, below). > > I've also forwarded your email to my team, with hope there is sufficient > interest to get people onto the developers email list. We're still > wrestling with several problems, and some interaction would seem warranted: > > - we haven't yet had success navigating a 'tree' (expanding '+' > buttons, collapsing '-' buttons, etc) > > There needs to better support for tree components in the API. Something we're taking on for the next release which should be out in about 2 weeks > > - > - we're trying to establish a good generic way to access UI components > that might exist in the header of a DataGrid (e.g., like a checkbox to > select "all" datagrid rows) [i.e., we're pretty much novices over here] > > There's a bug in the API that sometimes prevents interaction with objects embedded in other components. We're looking into this currently and will have a fix in the next release. Have you tried running the refreshIDTooltips command to see if the id can be located on the component? > > - > - non-unique IDs; we haven't yet deciphered how to uniquely scope > objects that have the same ID; the AppTreeParser code seems to support the > "/" character for scoping, we just have to figure out how to use it properly > > There are 2 main ways to uniquely identify objects with the same id: 1. using the "/" this is done by specifying a unique container component to narrow the search scope to that; followed by the id of the target component. For example myCanvas/myButton - this method is the most stable in terms of coping with changes on the UI. 2. using index for example myButton[3] - this is less stable as it can be hard to predict what index will be allocated to the component which can easily happen if the component are created in a different order for different test scenarios. > - > > Thanks for the information you sent us, and I'll let you know as soon as I > hear from the management. > > Steve > > > ------------------------------ > *From:* Fergal Hanley [mailto:fer...@gm...] > *Sent:* Tuesday, June 23, 2009 6:45 PM > *To:* Booth, Steve > *Cc:* Scott Galloway (sbg...@gm...); > sel...@li... > *Subject:* Re: Flex Selenium > > Hi Steve, > > Aswers and questions below: > > On Thu, Jun 18, 2009 at 2:36 AM, Booth, Steve <ste...@hp...>wrote: > >> >> ... stuff deleted ... >> >> It seems to me that some external influence might be necessary to deal >> with a cascading menu bar. An existing method, clickMenuBarUIComponent, >> works with a single menu cascade, but not for 2 or more. >> >> I'm new to this, so please bear with me. Given the (apparent) >> single-threaded nature of what I see in the ".as" files, it seems that after >> the first menu item is found, we need to allow a repaint to occur between >> each subsequent menu cascade. Only with the repaint will we find a >> populated MenuBarItem. >> >> ... stuff deleted ... >> > > The MenuItem object exists and is clickable even before a repaint occurs. > For example if you gave your MenuItem an id then you could just use the > flexClick command to directly click it without having to navigate the menu > and wait for cascade. That said I think this isn't the way tests should be > performed that require clicking menu items. > > Point of confusion: Suppose the MenuBar component is used to create > MenuItems in a data-driven manner, using the dataProvider property. Then > the MenuItem objects don't exist (yet), do they? > |