I am working on a VB6 legacy App (yes, very, very, very old app, migration is not an option). I have a button and a textbox (VB.TextBox). The textbox is intially disabled (e.g. Enabled = False). When I click on the button, the textbox should become enabled and get the focus.
This is the code for the OnClick event
Private Sub btnMAJ_Click(Index As Integer)
txtNom.Enabled = True
txtNom.SetFocus
End Sub
The problem is that when I check the value of txtNom.Enabled inmediately after I change it to True, it is still False, and when the code reaches the line txtNom.SetFocus it throws an error message
Run-time error '5'
Invalid procedure call or argument
because the txtNom control is still disabled. I don't understand what would be the problem.
This is a screenshot of the VB6 IDE with a watch on the value of txtNom.Enabled inmediatly after assigning True, you can see it is still False
Ok, so I found out the problem here. In this particular scenario, the txtNom control was inside a panel that was also disabled. The control was not enabled until I specifically set Enabled to True on the containing panel. So it seems the SetFocus will fail if any of the containers of the component is disabled, which makes sense, but the error message information is something I think Microsoft should not be too proud of.
Related
Context: In my rspec (using Ruby and Capybara)
I click on a link to test an action in my app: adding a branch to my app.
A modal window opens, where I select the branch, and then I click a "submit" button to add the branch to my app. After clicking "submit" the modal window is closed.
The rspecs continues by clicking "Save" in the main screen, to save the state of the application (and effectively saving adding the branch).
Problem: The rspec is failing because (seemingly) it is trying to click the "Save" button on the main screen while the modal window that is used to select the branch is still present. The test doesn't complain that it can't find the "Save" button component, but that it can't be clicked.
The error in the log is:
[...]Save</button> is not clickable at point (692, 23). Other element would receive the click[...]
A gotcha: this rspec passes correctly on some environments, like when it is run against my local server, but it fails when it is executed by our automation server. Thus, this test has been tagged as "flaky".
Potential solutions: Things we have tried so far:
Play around our "clicks configuration", making sure we are on "ready state" and that the modal window is gone. We failed with this, since we kept hitting the same error.
Implement a "wait". We added a loop to sleep for a bit while the modal window seemed to exist
XYZ.add_new_branch_name(#branch_name)
while Utilities.element_visible?(:xpath, myElement)
sleep(0.5)
end
XYZ.save
The while condition checks if the "submit" button of the modal window exists. The element_visible function uses
find(method,element).visible?
but I'm not sure if find should already take into account that the button may exist and be visible but not be clickable.
Since this still fails, in spite of all our effort to make sure that the modal is gone before we attempt to click on the "save" button, I want tot ask:
Is there a proper way to detect if an element behind a modal window is clickable or not using rspecs?
find only cares about "visibility", not "clickability" (and different drivers may have slightly different interpretations of "visibility"). The reason for the flakiness you're seeing is most likely speed of the machine running the tests which affects the timing of the modal animating away. The best way to solve this issue is to disable animations in the test mode (how you do that is dependent on exactly what library and/or CSS you're using for the animations). The other way is to do as you're doing - checking that the modal has disappeared before clicking the 'Save' button, however you should just be using the Capybara provided methods (which include waiting/retrying behavior) rather than writing your own loop for that.
expect(page).not_to have_css('css selector of the modal') # RSpec version
assert_no_css('css selector of the modal') # minitest version
After looking at the mouse position from your error, one other potential issue you may be having is with screen size and scrolling. If the page requires to be scrolled to get to the 'Save' button and (692, 23) would put the button behind a fixed header (you should be able to verify that by taking a screenshot before the button click attempt) then it may not be possible for whatever driver you're using to click the button. In that case you'd need to use execute_script to scroll the page to a different location so the button is not covered on the page and/or increase the "browser" size so scrolling isn't necessary in the test.
I had a similar problem and solved it by writing my own click_on_with_wait helper function:
def click_on_with_wait(text, wait_time: Capybara.default_max_wait_time)
success = false
(wait_time * 10).round.times do
click_on text
success = true
break
rescue Selenium::WebDriver::Error::WebDriverError
sleep(0.1)
end
# Try clicking one last time, so that the error will get raised if it still doesn't work
click_on text unless success
end
This will try to click on the element. If it's still hidden by the modal, the function will wait 100ms and then try again, until the given wait_time is reached.
Using Rails, I put it in system_spec_helpers.rb so that I can simply replace click_on 'Submit Form' with click_on_with_wait 'Submit Form'.
I have a page that I am navigating to that does some setup stuff via the 'OnNavigatedTo' event.
Thso page contains a TimePicker control and I have discovered that when I finish in the Timepicker control and focus returns back to my page it is again going through the 'OnNavigatedTo' event.
As a result is doing setup stuff again that is mucking things up, and if even has the same NavigationContext.QueryString as when I originally navigated to that page.
I assume I cannot avoid this event being called again - but is there any way to know that I have come here as a result of exiting the Timepicker control?
thanks
What about defining a bool in the class (instance-level, not static) that you set check in OnNavigatedTo -- if false, then do your work and set to true. Now, I'm not 100% sure that this works if you go back one level further and then tap on whatever brought up this page, so check that. Also, check to ensure everything works with tombstoning -- that's where you're more likely to have problems.
--randy
I am using Windows 7 and my project is in VB 6.0. I am getting errors while I am executing my program. It shows the error:
User-defined type not defined.
Here is my code:
Private Sub Toolbar1_ButtonClick(ByVal Button As MSComctlLib.Button)
Select Case Button.Key
Case "trace": Call mntrace_Click
Case "snrplot": Call mnSnrplot_Click
Case "skyplot": Call mnskyplot_Click
Case "nmea": Call mnNmea_Click
Case "navigation": Call mnNavigation_Click
Case "survey": Call mnSurvey_Click
Case "pause/start": Call mnpause_Click
Case "save": Call mnsave_Click
Case "print": Call mnprint_Click
Case "offline": Call mnoffline_Click
End Select
End Sub
How can I solve this error?
The compiler is automatically highlighting the first line of the function declaration for you when the error appears. That means the error occurs somewhere within that line. Sometimes that's not as helpful as you'd like, but in this case, it manages to tell you quite a lot.
Specifically, the only "user-defined type" (really, the only "type" at all) that appears in the function declaration is MSComctlLib.Button. What the compiler error message is telling you here is that it doesn't know what a MSComctlLib.Button is. It therefore assumes it's a "user-defined" type because it often doesn't know what the user is talking about. :-)
Either way, the fix is simple: you need to tell the compiler what an MSComctlLib.Button is. In this case, it guessed wrong in assuming that it is a user-defined type. It's actually a button control provided in the Microsoft Windows Common Controls Library. To tell VB 6 about this control, you need to add the corresponding component to your project. Follow these steps:
From the "Project" menu, select "Components".
In the dialog box that appears, scroll about 2/3 of the way down the list to the M's. Place a check by both the "Microsoft Windows Common Controls 6.0" and "Microsoft Common Controls-2 6.0" items. (Don't worry if yours have a different service pack designation.)
Click the OK button. If you're quick, you'll see some additional controls being added to your toolbox. These are the controls provided by the component libraries that you just added. Among those controls is one called Button.
Finally, try to compile and run your project again—everything should be fine this time, because now the compiler knows what the MSComctlLib.Button type is. In case you still don't, it's a button that appears on your toolbar. The toolbar control is provided by the Common Controls library, and it includes a type that defines an individual button appearing on that toolbar.
Sounds like you are missing a reference to an object library.
(Have you executed it without errors elsewhere?)
I think you just copied and pasted that code from elsewhere. Normally, if you wanted to reference MSComctlLib, you will normally do first the steps stated by Cody Gray here before you can access the Type Library.
We have a VB6 application that uses a non-visible window (form) for DDE communication.
We have some clients reporting that occasionally they can see this window on their desktop.
I did a scan through the code for any visible = true or show's on the form in question, but nothing.
This about all we do with it:
Load frmDDELink
frmDDELink.stuff = stuff
We don't actually explicitly display (or explicitly not display it either).
What could cause a hidden window to be displayed on a user's desktop such that it is visible?
Try and set the location of the form to off-screen.
frmDDELink.ClientLeft = -100
frmDDELink.ClientTop = -100
A misbehaving app on the client's machine could do that. FindWindow() is a notoriously inaccurate API function. On top of that, all VB6 windows have the same class name. Thunder something, iirc. It might be finding your window instead of the one intended, making the wrong window visible.
I like Black Frog's simple hint to set the location off-screen, and nobugz's possible explanation. I would also suggest handling the Form_Activate event and setting the form invisible again.
Private Sub Form_Activate()
'Log something for debugging purposes?'
Me.Visible = False
End Sub
try to set the border into none, or me.visible = false, and set the property not to display in the task bar.
I'm running into a problem trying to anchor a textbox to a form on all 4 sides. I added a textbox to a form and set the Multiline property to True and the Anchor property to Left, Right, Up, and Down so that the textbox will expand and shrink with the form at run time. I also have a few other controls above and below the textbox.
The anchoring works correctly in Visual Studio 2005 (i.e. I can resize the form and have the controls expand and shrink as expected), but when I run the project, the bottom of the textbox is extended to the bottom of the form, behind the other controls that would normally appear beneath it. This problem occurs when the form loads, before any resizing is attempted. The anchoring of the textbox is correct for the top, left, and right sides; only the bottom is malfunctioning.
Has anybody heard of this and if so, were you able to find a solution?
Thanks!
UPDATE:
Here is some of the designer code as per Greg D's request (I am only including the stuff that had to do with the textbox itself, not the other controls):
Friend WithEvents txtRecommendationText1 As System.Windows.Forms.TextBox
<System.Diagnostics.DebuggerStepThrough()> _
Private Sub InitializeComponent()
Me.txtRecommendationText1 = New System.Windows.Forms.TextBox
' ...snip...
'txtRecommendationText1
Me.txtRecommendationText1.Anchor = CType((((System.Windows.Forms.AnchorStyles.Top Or System.Windows.Forms.AnchorStyles.Bottom) _
Or System.Windows.Forms.AnchorStyles.Left) _
Or System.Windows.Forms.AnchorStyles.Right), System.Windows.Forms.AnchorStyles)
Me.txtRecommendationText1.Location = New System.Drawing.Point(4, 127)
Me.txtRecommendationText1.Multiline = True
Me.txtRecommendationText1.Name = "txtRecommendationText1"
Me.txtRecommendationText1.Size = New System.Drawing.Size(223, 149)
Me.txtRecommendationText1.TabIndex = 10
End Sub
ANOTHER UPDATE:
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
Is your Form localized? Check the resource files for an entry with Textbox.Size, delete is and reset the size.
Is your Form inherited and is the Textbox on the baseform? Try setting the Textbox's access modifier to Protected or Public.
Have you implemented custom resize logic? Turn it off and see if the problem is still there.
Have you entered a Textbox.MinimumSize/MaximumSize? Remove or change the value.
It might also be a combination of these things...
Does the form snap back to the expected layout when you resize it after it's been initialized weirdly? Also, have you set a Height or MinimumHeight/MaximumHeight property for the text box?
If possible, a few snippets from the designer code might be useful. :)
One possibility that I've run into in the past is DPI. If you're running/testing your code on a machine with a different DPI setting than the machine that you're developing on, you may observe some strange things.
The anchor functionality essentially establishes a fixed distance between the edge of a control and the edge of the control's parent. Is your textbox embedded within another control (e.g., a panel) that doesn't have its anchors properly set? Right clicking on the text box in the designer should pop up a menu that lets you select any controls that exist underneath it, also.
Does your program include any custom resize logic, or does it modify the size of the textbox programmatically outside of designer-generated code? That might also result in weird behavior. I've assumed maintenance for a number of pieces of software at my organization where the original developers spent a great deal of time implementing (buggy) resize logic that I had to tear out so that I could just let the designer-generated code do the work for me.
The textbox I originally posted about was not inherited from a baseclass form (although it was added to a custom User Control class; I probably should have mentioned that earlier), but I recently ran into the same problem on a totally unrelated set of controls that were inherited from a baseclass form. It's easy to blame these problems on possible bugs in the .NET framework, but it's really starting to look that way to me.
It's very likely because of the 'AutoScaleMode' property being set in InitializeComponent(). Try setting it to 'None' and see if that fixes it. I've had these problem a couple of times now.