I have a small app developed in VS 2010 with a StatusStrip at the bottom. I want to have two ToolStripStatusLabels in this StatusStrip, one always to the far left and one always to the far right.
I added the two ToolStripStatusLabels and set the Spring property of the first one to True, so that the second one is pushed over to the right. This works in my IDE and when I run the application on my Win7 computer. However, when I put this same application on another Win7 machine, the second ToolStripStatusLabel is always invisible. I changed the BackColor of both labels to something different and I could see both on my machine. On the problem machine, the 2nd one is completely invisible (no background color, just the Control color, no text).
I have experimented with various values in the StatusStrip's LayoutStyle property. If it is set to "Flow", the 2nd label does show up, but the first label is now all the way on the left, with the 2nd one right next to it. Again, I want the 2nd one to be all the way on the right.
Clearly, I do not have the right combination of settings to do this, but I am getting frustrated. I would appreciate any suggestions anyone might have. Thanks!
Related
I am developing a testing algorithm for our iOS apps using Appium. To fully implement this algorithm i need to identify wither i have moved onto different screen or am still on the same screen after performing some action. I need to know, what makes every screen unique/different from other in terms of Appium?
Going through the pageSource of every screen, i found that most screens have xpath attribute in window element. Can i use value of xpath of window element to mark the screen as unique from others, or do i need to do a trivial string comparison between screen's pageSources to mark them different? Or is there any other better solution?
Not sure if xpath would be the best solution for this. Normally the UIAWindow would remain the same, and developers might use different containers within this UIAWindow to render different screens.
So to verify different screens, you might need to figure out what this container is and see if the container's properties change when you move to a new screen (ie a new container)
If you app user a different header for every new screen, then you can use this header to see if the screen is changed. Example: in WhatsApp, you would see a different persons at the top. So in this case, the person's name can be assumed as the header.
If this doesn't work then you can verify some of the other controls, or say list of all the UIAStaticText on the screen. During screen change the entire list of UIAStaticText might change. So this can indicate a screen change.
For our automation suite at work I've implemented a series of screen check steps. Every time we switch screens I do a find_element command for an element on that screen that is unique to that screen. That way if a button or option takes me to a new screen that is incorrect my test will fail as expected. If it does find the element we're expecting it adds minimal time to the test suite.
Anish Pillai made a good suggestion of using the header text if there is any. Otherwise a particular tab, menu text, resource_id, or whatever is unique about the page would suffice. All you would need to do is a find_element call and a failure message if it fails.
I'm trying to use the Visual Studio AutoHistory extension.
However, when I select "Take Snapshot" (except for the very first time), I see no difference in the AutoHistory pane. The "Old" timestamp remains the same and the "Now" edit box (and "X" to its right) are read-only:
How can I verify that my snapshots are really being taken? I feel as if the lens cap is still on the camera or something. How can I compare my last two snapshots?
It's not enough to look at the filename list with the 'old' and 'new' columns. Instead you really need to hover over those tiny snapshot entries to get information on when AutoHistory is doing the captures. If you want to change the label of a snapshot, seems like the interface requires you to grab the top of the little range box and drag it down to just above the item in question. Only then does it seem to allow your snapshot's label to be changed:
So, drag this box...
...down to this spot, right above the snapshot you just took:
And, apparently, a snapshot's label value is changed when the textbox looses focus (there's little indication that you've updated the text).
If you want to compare two snapshots, you have to painstakingly set the box's bounds to that of the two snapshots you want to compare:
I do like the power of this extension, but the interface can be maddening and isn't very intuitive.
Looks like the author(s) have abandoned support for it since they no longer reply to comments or requests. Would be awesome if it were open source since it just needs a few tweaks to really take this thing across the finish line!
I started a new job a few weeks ago.
In my previous job, I was working with 2 screens. I know have 3 screens here (what an upgrade!)
I have always been bothered by a small bug, and since today I don't have a lot of code to do, I decided to finally try to solve this problem. The layout I want to achieve is pretty simple (see screenshots below): One file on the left screen, and another one on the right.
What happens is the following:
When I enter debug mode, the layout stays the same except one thing... the separation between two files (which is usually right between the two screens). Annoying for breakpoints and stuff, so I resize it, debug, and...
When I leave debug mode and go back to debug, the layout go back to what it was... except the separation which moved as well!
And last but not least, if I close Visual Studio and open it again, my two file views are now expanded on both screens, separated horizontally (<- this one is new, I had never seen that before).
Every time I go to debug mode, or go back to design, I would resize it to fit my two screens. And then it would shift again at the next debug. After some time it shifts with a smaller amount of pixels. Then, it just stops shifting, as if it learned that it shouldn't change. Until at some point, it goes back to normal and forces me to resize again.
I tried to use add-ons such as Perspectives or Layout O Rama , but they didn't keep any information about the two Code windows. No matter how I was saving them (let's say, one would be 20% of the left screen, and the other would expand on 2 screens), it would ANYWAY go back to the strange, shifted layout.
I also tried Visual Studio Productivity Power Tool and it's terrible. If I dock a code tab as a Window on my second screen, and dock for example the Find Results on it, it would be separated or reorganized every time I switch to Debug/Design
Has anyone experienced that yet? Am I the only one feeling that my Visual Studio is a pet who will learn how to do his own layout as time goes?
Thank you!
Also, as an image is always better than a description, here are a few screenshots:
Here, the normal, regular layout, with the red line being where my screens stop. Perfect, al dente layout allowing me to use the best of my two screens
Here, the one happening every time I go to debug. Notice how ONLY the code windows shifted (the bottom part with error list on the left and find results on the right didn't change at all )
And this is the one I get when I restart my IDE, forcing me to recreate my layout all the time
Thanks a lot!
I use Stata SE 11.1 on a Windows XP machine. I normally prefer to have the results, variables, and command boxes as three distinct boxes that are all visible at the same time. I accidentally clicked on something that merged them into one display and only lets me toggle between the three, showing only one at a time.
The first image below shows how I prefer it to look whereas the second one shows how it currently looks. How may I get the display to go the way that I prefer?
This is an image of the preferred display:
Above, is the preferred display.
Below, is the current display that I would like no longer.
Under Edit, go to Preferences, then Load Preference Set, then Factory Settings. If your preferred set up was the way Stata was initially set up, then this will get you there. Good luck!
A mere Windows textbox greatly surprised me today.
I have two unrelated text boxes inside an application. I can type in either text box and switch the focus by clicking on them. Then happens some event X, which I can't describe here for reasons given below. After this event happens, the two text boxes become "entangled" in an almost quantum way.
Say, text box A was focused before X happened. When I click text box B to type in some text, the new text appears in text box A, whereas the blinking cursor happily moves along in text box B through the void, as if the text were there.
No amount of clicking on either text boxes can resolve this. The cursor will always remain in B, whereas the text will always go to A.
Message spying reveals that after the event X, the text boxes lose the ability to lose or gain focus. When I click on B, WM_LOSE_FOCUS does not come to A, and WM_SET_FOCUS does not come to B. (The rectangles and visibility of the boxes are OK.)
The same thing happens in Windows XP and Windows 7.
Now, event X: it's a big event in a third-party UI library which I cannot reverse-engineer in a timely manner. (Namely, docking a pane in wxAUI.)
I am sure that this behavior is the result of incorrect WinAPI calls to the text boxes (garbage in - garbage out). I would like to know what could possibly cause such "textbox trip" to know where to start looking for the bug.
Thanks!
I found the problem. It was me. There was a silly bug in focus management. It caused the focus to be rapidly (immediately) transferred to text box B and then back to text box A immediately after "event X". And though it only happened once, it was enough to wreak havoc in the textboxes till the end of their lives.
Why the special effects? It turns out that Windows hates two rapid consecutive manipulations with UI elements. I once had a similarly weird bug when I tried to move a control by setting its origin and its size in two different steps. The control would behave very randomly after this. Only when I moved it properly - in one step - the weirdness stopped.
Thanks for your attention and sorry for bothering.
That's a pretty strange one, and without being able to look at some code the best I can do is an educated guess.
It sounds to me like the UI library is handling notifications (key down, focus, etc.) for text box B and acting on them as though they were meant for text box A. Like there's a variable like activeTextBox that holds the handle of text box A, even when it should be pointing to text box B.
Whereas I can imagine a UI library bug causing this kind of behavior, I would think it's much more likely that client code would cause it. Have you ruled out your code as the culprit?
Do the text boxes have unique identifiers?
did you tie their messages and message handlers up correctly?
In particular, it sounds like the control that has event X might have sub-control identifiers which clash with your control identifiers.
if the problem is reproducible, then I would make a small test example and send it to the control's vendor.