I have created a custom Close Opportunity script which is complete replica of CRM's default opps.js with exception that it has couple lines of code that I've wrote. I replaced default Close Opportunity ribbon buttons with my own and made everything work as it should work. There's one little problem I can't understand though.
I'm using VPN and remote desktop connection when I'm developing in this particular case. Everytime I open VPN and connect to the remote desktop, then open CRM and then click my Close Opportunity ribbon button my script wont work. Opportunity is closed correctly, but my custom logic is not run. If I reactivate the opportunity and close it again or in addition close another opportunity everything works just fine. I can't repeat this problem in any other way than just closing remote desktop and disconnecting VPN and then connecting again.
But that should not have nothing to do with how CRM works right? Or is there some cache or something I'm not aware of but which could cause this problem? Anyway, I'm keeping myself busy with this but any advices are welcome.
Edit: And I have tried to clear Internet Explorer's cache etc.
Can we see an example of the code?
Also when calling a webresource from the ribbon remember to reference using "$"
Example $webresource:SomeScript.js
Related
I'm working on a project using WebKitGTK and I'm having trouble with the WebInspector after having enabled it using the enable-developer-extras property.
I can open it fine, but when I click the close, pop-out into own window, or switch to sidebar buttons they don't do anything. In my application there's literally no way to close WebInspector once you've opened it.
It doesn't appear to be anything I've changed in my code because I remember it working before, but when I check those commits from Git they're now broken as well. At the same time however it does look like something I'm doing because other applications on my computer using WebKitGTK have their WebInspector working perfectly (and yes, I checked out their code).
So my question is: Has anyone faced a similar issue? And does anyone have an idea how it might be fixed?
You're probably hitting this bug. Workaround is to add a dummy call to webkit_web_view_get_inspector somewhere.
Okay, I have had the most aggravating problem with OpenFileDialog1. I have a program that I've been using for some 8 months, and in the past month, the program has begun to hang randomly when utilizing the OpenFileDialog1.ShowDialog() function. I have already read through all of the other posts about multi-threaded vs single threaded application. This did not fix it. Enabling the "Show Help" button did not fix it. I am mostly at a loss. here is a thorough walkthrough of the bug:
Run the application. I can always use the Open File button a few times with no problems. It freezes randomly after the program has been running for awhile.
The freeze happens after I push the ShowDialog button, and never displays the Open File Dialog window. The entire program locks up and hangs. If I pause it, Visual Studio doesn't show an error. It underlines the OpenFileDialog1.ShowDialog() in green, which is very odd.
I have found a way to break the freeze. Simply run a second instance of the program and use the OpenFileDialog function. As soon as it loads the file in the second instance, the first instance unfreezes. However, this is not a fix.
The only thing I can think of that may be causing this is the program also uses a WebBrowser1 control. It only seems to happen AFTER the WebBrowser control, which is on a seperate form, not the main form, has been initiated and utilized. Does this make any sense at all?
Thank you for anyone who can help me. I am about to tear my hair out.
Debug your program with dnspy, And when the software freezes, you will be able to see within the dnspy the actual code even if it is in a third party DLL.
I have solved this problem. It was quite unsolveable based on my description above, but hopefully I will help someone with this solution. The error is related to using the IE11 Emulation Control (11000) in the WebBrowser1 control. For some reason this interferes with OpenFileDialog and causes it to hang. I have no idea why. I changed my WebBrowser1 to use IE9 Emulation Control (9999) and the error has gone away. Thank you to those who looked into this. This is a registry entry in HKEY_CURRENT_USER.
I have an App that I inherited in VB6 and have ported mostly to VB.net
When I compile / run the app - it highlights all the files in the current selected folder.
What makes it worse, is it's very difficult to search online as what search terms does one use?
The app was ported to VS 2005 - quite successfully - but this has me stumped...
I have tried commenting out all the code that's run on startup and it still does it, so it must be some sort of background thing...
Any ideas?
I can't find an old version of my app to see if it's changes I have made and I don't know where to begin. See the image:
The top part is before I run the app, the bottom is once the app is running and has focus. I hope it makes sense
Also, if I'm browsing and then run the app, and go back to the browser, when my app gets the focus again, the webpage goes back to the top...
The folder is just an example - Basically when I compile (or later run) my App, if I go to Windows Explorer - when the app gets focus - whatever folder I am in has all its files highlighted. If instead of going to Windows Explorer, I go to a web browser, when the app gets focus the browser goes to the top (similar to Home).
There is Windows Integratio, but I have commented out what I can and still am no closer.
Does this info help?
I found the problem - after going back to the vb6 project and removing everything except for the 5 modules needed to startup and I eventually tracked the problem.
There was some code being called when two edit boxes received focus which called send keys home and end - hence it would go home - select all files to the end. I had deactivated one of the edit boxes to not receive focus and it helped temporarily(obviously until the other box got focus), but since deactivating the send keys when they get focus has helped. Albeit an arbitrary problem, maybe it will help someone in the future..
I have a strange situation. IT installed SSMS on my laptop and it runs well the first time, connected to my SQL servers remotely etc. But then it's frozen. I forced quit and then started SSMS again. Now it's totally frozen, no popup window at all to enter the server-connection text string. Then I did a force quit and got a pop up window (see it here ).
Microsoft SQL Server Management Studio has detected that an operation is blocking user input. This can be caused by an active modal dialog or a task that needs to block user interaction. Would you like to shut down anyway?
Has anyone seen this before? My IT department has no clue.
Often this is due to the new connection dialog being off screen (usually due to changing monitor setup e.g. 1 to 2 monitors or resolution change etc).
If so the really easy fix (if your connection dialog just needed approval without changing fields) is :
Focus on SSMS and Hit Enter/Return
..or the easy fix (if above does not work - as your last connection is not ready to go) is:
Alt Tab to SSMS
Alt + Space - context menu
M - select Move (in offscreen context menu)
Arrow Key(s) - to move it back onto screen
As per answers here from #Eirik Toft and here from #Lee Chetwynd
Fixed an issue which presented the same on my machine today by renaming a entry in my registry:
After some digging there seems to be multiple issues that can produce the same error (Application, settings, registry). This blog entry covers it pretty well:
http://www.armedia.com/blog/2012/08/sql-server-management-studio-freeze/
In my case deleteing the SQL server management studio folder under AppData ( c:\users\%userName%Appdata\raoming\microsoft\ ) didn't work.
However I was successfully after deleting / renaming the regisitry entry:
[HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server]
(update)
Worked out the underlying issue on my laptop - was using additional 2 screens with much higher resolutions which caused windows / SSMS to open up the connect to new data source dialog off all of them. If your using multiple screens try returning to just use the native laptop screen to see if you can find the dialog that SSMS is waiting on your input for.
I just had this same situation, with two additional screens connected to my laptop. SQL Server Management Studio was opened on the third screen, with the modal dialog nowhere to be seen.
Two options:
Press tab three times and enter. This cancels the dialog. Now you can move the window to another screen.
Set Windows to only use one or two screens. SSMS opens on the first and should still open there when you move back to using three screens.
When SSMS is on your primary or secondary screen, the modal dialog opens on the first and should be usable.
It was because multi screen display. Turning off multiscreen to single one resolved it. Reenabled multi screen display after ssms started working
In my case, "Run as Administrator" option worked like charm. I was accessing my server screen with the windows RDP. And when I open SQL Server Management Studio and Visual Studio 2010 user hangs at the moment and wont operate unless sign off r disconnected by administrator.
But when I set compatibility mode of both the application to the "run as Administrator", it starts working fine.
the problem also occurs if you have a touch screen. I fixed this by disabling the local thouch screen when I switch to RDP.
I have a virtual machine (VMware) with Mercury Quick Test Professional 9.2 installed. I have a script to test an application, written in VB.NET using the Infragistics library.
If I access this virtual machine using my laptop (using Remote Desktop), everything works fine, the script completes without a problem. My laptop runs XP, with Windows Classic theme.
If I access this virtual machine using another machine (using Remote Desktop), the script starts fine, but stops halfway through, without no error message from QTP, nothing. This machine runs XP, with Windows Classic theme.
One difference between the two setups is the size of the screen, the laptop is 1920x1280, other machine 1280x1024.
The step where the script stops involves checking a checkbox within an UltraWinGrid. The checkbox itself is displayed, is on the screen in both cases.
Has anyone had this problem before, or have any idea why the behaviour is different between the two machines?
Thanks.
OK. I've found the problem. In fact, the script was failing silently because that's what the person who wrote the script told it to do. It couldn't validate something which was off screen, so the script failed.
The problem was the QTP definition of 'off screen'. I have two screens attached to my laptop, the screen for the laptop itself (1920x1200) and another screen (1280x1024). I connect to the VM for QTP using remote desktop, and it uses the settings of the screen for the laptop. This means that when I launch my QTP script, and move it to the other screen, it doesn't fit, so the screen is no longer maximized, and the object is partially off screen, so can't be found.
The fix is simple: in the Remote Desktop, use the Display tab, and set the size of the screen to a size to 1280x1024, and QTP doesn't have any more problems.
Voilà.
If you are not using Expert Mode, and / or are allowing QTP to do most of the work to create your repository objects, then yes it is referencing everything by pixels.
I create all of my repository objects by hand, viewing the source (in the case of automated web-application testing) and using the Object Spy for assistance where needed. I make a point to not have any positioning information as part of my object definition, for the very reason you are running in to.
For the parts of my web-app that interacted with Windows (opening a file to upload, etc.) the Object Spy was essential for the trial and error necessary to create a unique identifier for creating the repository object. But it can be done.
Ex1: File Browse Dialog
text = "Choose file"
nativeclass = #32770 (apparently some Windows VooDoo for a file open dialog?)
Ex2: Filename textbox in Browse dialog:
nativeclass = "Edit"
attached text "File &name:" (more Windows VooDoo? It woudn't work for me without the "&")
Ex3: Open Button in the dialog:
text = "&Open"
object class = "Button"
Good Luck!
Point of clarification: You mentioned that QTP stops with no error message. Does that also mean that the test results log file also has no error message? If the log has any information, that may be helpful in diagnosing the problem. Could you share the lines of code at the point where the script fails?
Also, remote desktop will resize the desktop on the remote machine. Although QTP scripts are not inherently coordinate based, individual statements can be coordinate-based relative to an object. The resolution could be an issue in that regard. For example, imagine you had a line like Button.Click(5, 150) recorded on a higher resolution machine. But if you attempted to play it back on a lower resolution machine, and the 150 is out of bounds of the object on the lower resolution, it could cause an issue.
QTP does not use screen coordinates except as a last resort, if the objects are identified as high level objects (SwfTable in this case) you should be OK, if however QTP doesn't recognise the object it falls back to WinObject and screen coordinates.
If you're using Infragistics then you should know that they extend QTP's support with their TestAdvantage product which will probably solve your issue.
Edit:
#MatthieuF said:
In fact, we use the Infragistics plugin for QTP, and we still have the problem
Can you give me an example of a line that fails?
A few things:
You should be able to debug on the VM easily - just wait for it to stop, go into your object repository, and see if it can identify the object. If no then use object spy to figure out what properties are different between the OSes. If there is a difference then you can always set that property to a regular expression and have it check for both possibilities.
Assuming that isn't the issue we've run into problems using remote desktop with QTP if the Remote window is closed or minimized. For us, it was an issue where the clipboard can not be changed when an RDP window isn't visible, but there could be other surprises when using QTP that way.