Several developers on my team have this problem. We can run our app in the IDE fine, but when we eventually quit the app, the IDE itself will then crash.
The crash takes the form of
"Visual Basic has stopped working"
It doesn't matter if we quit our app nicely or force-stop it in the debugger; same result (crashed IDE).
The exit sequence for the app is:
User selects 'exit' from a menu
Menu event handler calls Unload Me
Form_QueryUnload event handler fires
Form_Unload event handler fires. It does:
'close all sub forms
For i = Forms.Count - 1 To 1 Step -1
Unload Forms(i)
Next
Then saves some data and then does Exit Sub.
We tend to run a group file with a 5-6 projects in it.
This error sometimes seems to go away, other times it occurs, seemingly randomly. I don't know what factor influences this.
If we don't actually run the app, just the IDE, then it works fine and we can quit the IDE itself normally.
Anyone seen this before? Any ideas? Thanks!
This is most definately caused by leaks of VB6 objects that are involved in subclassing/hooking and not only these.
What we did to get rid of these crashes was to instrument all of our classes (including forms, user controls, designers and anything that can be instantiated) with DebugInstanceInit and DebugInstanceTerm calls in respective Class/Form/UserControl Initialize and Terminate events.
Public Sub DebugInstanceInit(sModuleName As String, sDebugID As String, oObj As Object)
Public Sub DebugInstanceTerm(sModuleName As String, sDebugID As String)
These basicly track at any time how many and what kind of instances the application is using. Each instance is assigned a unique sDebugID in DebugInstanceInit that is used as a key in DebugIDs collection. This collection is instantiated empty in Sub Main and when application teminates (i.e. in main form's Form_Unload) this collection has to be empty or with a fixed number of instances left (for instance exactly 4) otherwise its content is the kind of objects we are leaking.
What fixed the IDE crashes?
Notice the collection is instantiated as late as Sub Main which means it has to remain Nothing at design-time. We just put a simple check in DebugInstanceInit like this
If DebugIDs Is Nothing Then
If Left$(sModuleName, 3) <> "ctx" Then
DebugPrint "DebugInstanceInit", "mdErrorHandling", sDebugID & " " & LIB_NAME & "." & sModuleName & "." & FUNC_NAME_INITIALIZE & " (This should not happen)"
End If
Else
...
End If
Basicly this prevented anything other than raw UserControls placed on forms from being instantiated at design-time. This includes GlobalMultiUse objects, this includes anything UC properties are accessing as UC properties are kind of routines that are certainly accessed at design-time.
So we had to sprinkle most of the UC's code heavily with Ambient.UserMode checks like this
If Ambient.UserMode Then
Set .Picture = LoadStdPicture(ucsPicHelp)
End If
It turned out our LoadStdPicture global function was instantiating some cDibSections for instance. The nice thing is that once you put a break-point at (This should not happen) debug print statement, the call-stack shows you exactly the offenting property of the offending UC.
I believe another answer is correct in its technical assessment of the cause of the problem. But it may also be useful to briefly describe the procedure I used to narrow down the source lines of code. In my case this problem appeared to be TOTALLY random, so it was hard to know where to start.
My approach was not rocket science - more brute force. Essentially I used a binary search to rule in/out sections of code. First step was to comment out the entire startup procedure so that the app would start as an empty shell; this demonstrated that the problem went away (null result).
Following that I recursively commented in roughly half the code, testing for the problem each time. Each block was evaluated as a boolean - it either did or did not cause the problem. Then proceed again in the block not ruled out.
Eventually (and more quickly than I anticipated) this led to a single line of code which accessed a property of a third-party control.
Related
I need some help with selecting a value from a dropdown list. The dropdown is a WebElement, and the flow works well up to the point where the value should be selected.
My code is as follows:
.Browser("Browser").Page("PageName").WebElement("DropDownList").Click
.WebList("ListOfItems").Select(itemToSelect)
Note: itemToSelect is the name of the item that needs to be selected from the list, which is being passed as a parameter within the function.
When running the code, I get an unspecified error.
The weird thing is that before the error is thrown, I can see the value being selected from the list in the browser, as upon selecting it, some fields in the form change. Also, if I press "Skip" in the error message panel, the process goes on as if nothing happened.
I am certain the error comes from .WebList("ListOfItems").Select(itemToSelect) but I do not know what to do in order to fix it.
Try this code.It works for me.
StrAllItems = Split(Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetRoProperty("all items"),";")
For intCounter = Lbound(strAllItems) to Ubound(strAllItems)-1
If Browser("name:=.*").Page("title:=.*").WebList("name:=.*").GetItem(intCounter)= "SomeValue" Then
Browser("name:=.*").Page("title:=.*").WebList("name:=.*").Select (intCounter)
Exit For
End If
Next
Please let me know if this help.
If the test behaves correctly and you're just getting an superfluous error you can just ignore this specific error. It's best of course to understand where the error comes from, you should probably contact MicroFocus support but in the meantime you can turn off error handling for the offending line.
Browser("Browser").Page("PageName").WebElement("DropDownList").Click
On Error Resume Next ' turn off error handling
Browser("Browser").Page("PageName").WebList("ListOfItems").Select(itemToSelect)
On Error Goto 0 ' turn error handling back on
BTW, I changed your code a bit to make it valid, I assume this is what your code really looks like.
Possible timing issue: You might need to wait for the hole list to appear before you select the item.
Often, the item exists, but the app is still updating its GUI.
Whenever you access the GUI with UFT while the app is not idle (f.e. not ready for user input because it is still updating its HTML), you might get all kinds of strange results, including unexpected errors, hangs, instability.
So how do you wait for the list to be complete? I don't know, because it heavily depends on the way your app is refreshing its GUI. You need to explore that, and integrate some synchronization code that waits for the right condition to be met.
Unfortunately, this is a hell of a job sometimes.
A suitable workaround (and a good way to verify if my hyphothesis is correct) might be to insert a large delay between the first click and the list item selection click. (A quick way to do a similar thing is to single-step through the code.) If that does not generate any error or issues, you can be pretty sure it is what I describe, and you can experiment with lower delay durations to find a good value.
Thanks to everyone for your replies.
The issue turned out to be due to the object not being added well to the repository.
It was eventually fixed by adding it properly.
I'm debugging a project using VS2012 ultimate, but encountered this problem very often now. usually it happens when i want to expand a collection type value(e.g, List<>, Dictionary<> and so on) to watch its value. It just failed to show the value and then hangs forever, the error message is like
"Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation." the only thing i could do is to restart the debugger.
can anybody give some help?
When you expand a value in the debugger to see its members, the debugger does somethings called a "func-eval" behind the scenes, which basically means it 'wakes up' one of the the threads in the debuggee and runs some code in it in order to display its result. This is usually either executing a property's getter or an object's .ToString() method.
Sometimes, the evaluation can take too long (often because a property getter gets stuck waiting on some lock that is held by another thread, in which case, you could keep waiting forever and it'll never return, because all threads except the thread that's doing the func-eval are paused by the debugger). In these cases, after a short while the debugger will decide to 'give up' and display the message you've encountered. You don't have to restart your app to try evaluating properties again - you can simply do another Step Over (F10).
As a more permanent solution, you can do one of two things:
Go into Tools->Options->Debugging->General and disable "Enable property evaluation and other implicit function calls". This will make the debugger's display a lot less useful as you will only be able to view fields, but it guarantees you will never get stuck and receive the timeout message.
Try to figure out which property in which object is the one that keeps timing-out. This can be a bit tricky, by try paying attention to which objects you are viewing when this happens - the timeout will usually occur just after you scroll down to the offending property. Once you know which property is at fault, either change it into a method, or put [DebuggerBrowsable(DebuggerBrowsableState.Never)] above it to prevent the debugger from displaying it.
We have a legacy PowerBuilder 12.1 Classic application with an Oracle 11g back end, and are experiencing performance issues in production that we cannot reproduce in our test environments.
The window in question has shared grid/freeform DataWindows and buttons to open other response windows, which when closed cause the grid to re-retrieve.
The grid has a very expensive query behind it, several columns receive their values from function calls with some very intense SQL within, however it still runs within a couple seconds, even in production.
The only consistency in when the errors occur is that it seems to be more likely if they attempt to navigate to the other windows quickly. The buttons that open said windows are assuming that a certain instance variable is set with the appropriate value from the row in focus in the grid. However, in this scenario, the instance variable has not yet been set, even though it looks like the row focus change has occurred. This is causing null reference exceptions that shouldn't be possible.
The end users' network connectivity is often sluggish, and their hardware isn't any less capable than ours. I want to blame the network, but I attempted to reproduce this myself in development by intentionally slowing down the SQL so that I could attempt to click a button, however everything happened as I expected: clicking the button didn't happen until after retrieve and all the other events finished.
My gut tells me that for some reason things aren't running synchronously when they should, and the only factor I can imagine is the speed of the SQL, whether from the query being slow, or the network being slow, but when I tried reproducing that effect things still happened in the proper sequence. The only suspect code is that the datawindow ancestor posts a user event called ue_post_rfc from rowfocuschanged, and this event does a Yield(). ue_post_rfc is where code goes instead of rowfocuschanged.
Is there any way Yield() would cause these problems, without manifesting itself in test environments, even when SQL is artificially slowed?
While your message may not give enough information to give you a recipe to solve your problem, it does give me a hint towards a common point of hard-to-diagnose failures that I see often in PowerBuilder systems.
The sequence of development events goes something like this
Developer develops code where there is a dependence on one event firing before another event, often a dependence through instance or global variables
This event sequence has been something the developer has observed, but isn't documented as a guaranteed sequence (like the AcceptText() sequence or the Update() sequence are documented)
I find this a lot with posted events, and I'm not talking about event and post-event where post-event is posted from event, but more like between post-ItemChanged and post-GetFocus
Something changes the sequence of events, breaking the code. Things that I've seen change non-guaranteed sequences of events include:
PowerBuilder version change
Operating system change
Hardware change
The application running with other applications taxing the system resources
Whoever is now in charge of solving this, has no clue what is going on or how to deal with it, so they start peppering the code with Yield() statements (I've literally seen comments beside a Yield() that said "I don't know why this works, but it solves problem X")
Note that Yield() allows any and all events in the message queue to be processed, while this developer really wants only one particular event to get through
Also note that the commonly-seen-in-my-career DO ... LOOP UNTIL (NOT Yield()) could loop infinitely on a heavily loaded system
Something happens to change the event sequence again
Now when the Yield() occurs, there is a different sequence of messages in the queue to be processed, and not the message the developer had wanted to be processed
Things start failing again
My advice to get rid of this problem (if this is your problem) is to either:
Get rid of the cross-event dependence
Get rid of event sequence assumptions
Manage the event sequence yourself
Good luck,
Terry
P.S. Here's a couple of quotes from your question that make me think of Yield() (not that I don't love the opportunity to jump all over Yield() grin)
The only consistency in when the errors occur is that it seems to be
more likely if they attempt to navigate to the other windows quickly.
Seen this when the user tries to initiate (let's say for example) two actions very quickly. If the script from the first action contains a Yield(), the script from the second action will both start and finish before the first action finishes. This can be true of any combination of user actions (e.g. button clicks, menu clicks, tabs, window closings... you coded with the possibility that the window isn't there anymore after the Yield() was done, right? If not, join the 99% of those that code Yield(), don't, and live dangerously) and system events (e.g. GetFocus, Deactivate, Timer)
My gut tells me that for some reason things aren't running
synchronously when they should
You're right. PowerBuilder (unless you force it) runs synchronously. However, if one event is starting before another finishes (see above), then you're going to get behaviours that look like asynchronous behaviours.
There's nothing definitive in what you've said, but you did ask about Yield(). The really kicker to nail this down is if you could reproduce this with a PBDEBUG trace; you'd see which event(s) is(are) surprising you. However, the amount that PBDEBUG slows things down affects event sequences and queuing, which may or may not be helpful.
My application is a windowing application that performs certain complex mathematical algorithms. Because I started with the application a long time ago, most of it is still single-threaded. To be more precise, the main thread executes all the complex calculation logic. It's important to mention that during the calculations, I show some progress on the screen.
In most cases, the mathematical algorithms only take several seconds, so after the user has started the action, an hourglass (or the running circle in Windows 7) is shown, and a few seconds later the results are shown.
In some cases, the algorithm can take several minutes. During this time, I show the hourglass, and while the algorithm is busy, I show the progress in my window. But, if the user clicks in the application after it has been busy for a while, the Window becomes 'more white' (as if a non-completely-transparent piece of plastic is laid over the window), the Window is not updated anymore, and Windows reports 'the application is not responding'.
I use Qt and I use the Qt function QWidget::repaint to force a repaint while my algorithm is busy. The repaint works for some time, but as said above, Windows seems to block this after a while.
What is the correct way to tell Windows that your application is still busy so that the window keeps on updating? If I enter an explicit message loop, the user might trigger other actions in the application which I don't want.
Is it enough to call PeekMessage?
It is enough to call GetMessage?
Or should I call DispatchMessage? And how do I prevent the user from starting another action (actually, prevent all user input)
Should I call one of these messages every time I update my window, or can I limit myself to call it every few seconds (10 seconds?, 30 seconds? ...)
Notice that moving the calculation logic to a separate thread is currently not an option.
I'm using Visual Studio 2010 on Windows 7, in combination with Qt 4.7.
You should separate the GUI from the application logic. All other solutions are hacks. Moving the calculation logic to a separate thread can easily be achieved with Qt using minor effort.
I assume that there is a function (lets call it execute()) that when called performs all these time consuming mathematical operations. One option is to use the Qt Concurrent API for calling this function in a separate thread, without using low-level thread handling.
What you need is the QtConcurrent::run function :
The QtConcurrent::run() function runs a function in a separate thread.
The return value of the function is made available through the QFuture
API.
Instead of simply calling execute() which will block your User Interface you can do the following (let A be the class in which execute() is defined):
QFuture<void> future = QtConcurrent::run(this, &A::execute);
You can use QFutrureWatcher in order to get notified about when the function has finished.
You could simply call QApplication::processEvents() from time to time, say every 2 or 3 seconds or so. That should trigger a repaint event and refresh your progress bar and other elements.
Similar question and lots of info here:
I need a message pump that doesn't mess up my open window
However, as you probably already know, this is quite a hack and it would be better to try to move the code to another thread. Why is this "not an option"?
The DisableProcessWindowGhosting function (see http://msdn.microsoft.com/en-us/library/ms648415(v=vs.85).aspx) tells Windows that it must not show the 'ghost window' if an application is not responsive.
My colleague did some experiments with it and noticed the following:
the animation showing the progress continues nicely (this is actually what I wanted to achieve)
the user can still minimize, move, ... the window (great)
on the downside: if the application is really hanging, the user must use Task Manager to kill it
So, this solves my problem.
now I'm developing a GUI with pop-up windows, so actually it is a workpackage with multiple GUIs.
I have read thorough the examples given in help files (changme, and toolpalette), but I failed to animate the method to transfer data from the new one back to the old one.
Here is my problem.
I have two GUIs, A, the Main one and B that I use it to collect input data and I want to transfer the data back to B.
Question 1:
I want to define new subclasses of handles in A.
lets say,
handles.newclass
how can I define its properties, e.g. 'Strings'?
Question 2:
In A, a button has the callback
B('A', handles.A);
so we activate B.fig.
After finished the work in B,
it has collected the following data (string and double) in B(!)
title_1 itle_2 ... title_n
and
num_1 num_2 ... num_n
I want to pass the data back to A.
Following the instruction, I wrote the codes shown below.
mainHandles = guidata(A);
title = mainHandles.title_1;
set(title,'String',title_1);
However, when I go back to A, handles in A was not changed at all.
Please someon help me out here.
Thank you!
=============update================
The solution I found is adding extra variables (say handles.GUIdata) to handles structure of one GUI, and whenever the data are required, just read them from the corresponding GUI.
And It works well for me, since I have a main control panel and several sub-GUIs.
There is a short discussion of this issue here.
I have had similar issues where I wanted external batch scripts to actually control my GUI applications, but there is no reason two GUI's would not be able to do the same.
I created a Singleton object, and when the GUI application starts up it gets the reference to the Singleton controller and sets the appropriate gui handles into the object for later use. Once the Singleton has the handles it can use set and get functions to provide or exchange data to any gui control that it has the handle for. Any function/callback in the system can get the handle to the singleton and then invoke routines on that Singleton that will allow data to be exchanged or even control operations to be run. Your GUI A can, for instance, ask the controller for the value in GUI B's field X, or even modify that value directly if desired. Its very flexible.
In your case be sure to invalidate any handles if GUI A or B go away, and test if that gui component actually exists before getting or modifying any values. The Singleton object will even survive across multiple invocations of your app, as long as Matlab itself is left running, so be sure to clean up on exit if you don't want stale information laying around.
http://www.mathworks.com/matlabcentral/fileexchange/24911-design-pattern-singleton-creational
Regarding Question 2, it looks like you forgot to first specify that Figure A should be active when setting the title. Fix that and everything else looks good (at least, the small snippets you've posted).