I work in a company that started using VDIs for certain SQAs. We have just noticed that in Microfocus ALM in the VDI only, when anyone tries to print a report through the Document Generator, an error occurs. See first screenshot. If you close this out, it freezes the browser and you have to close. When you try again, you'll get the second error below. In researching these, it seems the first could be caused by a Word incompatibility, which we have checked and ruled out. The second can be caused by files in the path of the TD_80 folder, which we have tried to remove as suggested, but the error persists.
Does anyone know what else might cause this error on the VDIs only?
Details from first error
Details from second error
After submitting a ticket to Micro Focus, they said Report Generator is no longer supported. They pointed us to their documentation on creating reports in the Analysis View module under the Dashboard. This seems to work similarly, but the filtering is a little bit different.
Related
During my process there is a drop-down html element that I have spied and set correctly. I run through the Object and Process studio without any issues. Once the same process is ran through the Control Room the element throws and error that it cannot be found.
I have tried multiple different configurations without any luck and the element is still found without issue when ran manually. I even checked by signing into the VM having it error and on the second retry had the VM up; at this stage the element was found without issue. It seems to only be when the bot is running and the screen is not up. No other elements give this issue and the next step is the same dropdown, but for a stop time not start.
Any help would be appreciated!
I have added pics of the STARTSPIED - START and ENDSPIED - END spied configs,the Navigation Stage, and the process correctly running in the Object Studio OB Studio correct.
Thank you!
For the person who down-voted this item...Configs here are my two days of config changes and research that I tried on my own before asking for help. This is my 5th automation that I have put into deployment without help, so thank you for down-voting someone trying to get help where they are stuck.
Your problem is most likely connected with the fact that processes run in the control room are executed much faster than in studio and your webpage might not be loaded on time (that would explain why it works after retry).
Best practice approach would be to add a dynamic wait stage after attach and use “Parent Document Loaded” option on the element you want to interact with. It will wait for the page to be loaded and then check exist for the element. I would also suggest splitting your action into two, first to set start date and second for end date.
Our legacy MDI desktop application uses the /dde switch in the association. When opening a file associated with it, and the application has not yet started up, Explorer pops up the following error:
There was a problem sending the command to the program.
The registry looks something like this:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document]
#="App File"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\DefaultIcon]
#="d:\\Program Files (x86)\\MyApp\\version\\app.exe,1"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\open]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\open\command]
#="\"C:\\Program Files\\App\\app.exe\" /dde"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\open\ddeexec]
#="[open(\"%1\")]"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\print]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\print\command]
#="C:\\Program Files\\App\\app.exe /dde"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\print\ddeexec]
#="[print(\"%1\")]"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\printto]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\printto\command]
#="C:\\Program Files\\App\\app.exe /dde"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\App.Document\shell\printto\ddeexec]
#="[printto(\"%1\",\"%2\",\"%3\",\"%4\")]"
Just to be clear, I just took these entries from the registry. I'm not well versed in what they do, but I can hazard a guess that they link the verbs to actions by way of the DDE interface.
Note that if the application has already started up, the document opens up fine in that instance. This is only an issue if the application hasn't started up and must execute a new instance of the application.
So, what is happening is that the associated file is opened through Explorer by double clicking on it, and the associated application is executed. Explorer would then pop up that message and our application would do nothing. Double clicking on the file a second time would then open the document.
We've had this issue previously, but we just decided to ignore it for a few years as no one really knew what it was and we had other priorities at the time. Our workaround was to tell the user to change the /dde to "%1". Yeah, lame, but it worked well enough. One issue with doing that though, was that it would execute a new instance of the application, regardless if the application was already running or not.
Anyways, this issue is now starting to become an actual problem and needs to be fixed. One of our developers is saying that the DDE system is antiquated and we should try writing a COM component that will redirect to our application like Visual Studio does as debugging this issue could take a while. I've not verified that yet, nor researched how much effort that would be. However, either may be resource intensive, either on the debugging or the research side, so I'm trying to do some preliminary research to see what I can dig up and determine which is the better approach.
Stepping in the code, I was able to determine that it gets to a ::SetWindowPlacement() call and stepping over that will cause the error message box to pop up (if Explorer hasn't timed out first). As it is a WINAPI, I cannot step into that function to see what it is doing.
The application is written mostly in VC/VC++ using MFC/API and other libraries.
So my question is, does anyone know why this is happening and how it can be fixed?
Edit
Some additional information:
I was able to intercept all of the SendMessage()/PostMessage()/DispatchMessage() function calls non-destructively, which will log all of the messages. This was achieved by using MS Detours 3.0.
What I am seeing is that there are 4 SendMessage calls with a WM_COPYDATA message which appears to be coming out of shell32.dll. However, it doesn't appear to be the messages that are at fault though.
Putting a __debugbreak() when it detects the WM_COPYDATA message results in no error until a few steps beyond. How far depends on if I step or if I put a breakpoint and run the code to somewhere beyond where I thought I was getting the error. Using DebugBreak() seems to slow down the debugger to the point where I can't step without the error showing up.
What I can't understand is that there doesn't appear to be any rhyme or reason as to what is triggering the error message to pop up. I doesn't appear to be a timeout as the timeout appears to be long until I start stepping in the code, and sometimes no messages are being Sent/Posted by the code. So there's no WM_DDE_ACK (or any message for that matter) being sent back to the Explorer window that has initiated this. This is very frustrating.
To further complicate things, if I use the intrinsic __debugbreak() call and I have a breakpoint somewhere else in the code, it sometimes can stop at that breakpoint rather than stopping at the __debugbreak(). And sometimes, when I run the code immediately when I get control of the debugger, it will sometimes result in a second break, as if it hit another __debugbreak(). What's that all about? Inconsistent debugging is certainly making this issue even harder to track down. >:(
This DDE stuff is still the in use for MDI interfaces. So if one EXE opens different files.
If you can launch you application multiple times and this is OK, for the customer, switching the entries in the registry to the normal place holders from the SDI is OK too.
Usually this message is shown from the explorer, if the EXE doesn't get ready in a specific time to accept the DDE commands.
So the main question for you is: What is changed or so slow in the application that the DDE messages are not retrieved.
On case would be if it takes a real long time until the message loop starts. A running message loop for the main window is required for DDE support.
SetWindowPos istself will not be the problem, but it might cause hundreds of messages (WM_SIZE, ...) to be fired to your application, and every handler in your application here might be the problem.
Just place a little timer inside the application in front of the SetWindowPos and check how long it takes to return...
Check how long the app takes, until InitInstance is exited with TRUE. After InitInstance exits CWinApp::Run starts and the message loop starts.
I've run into the same problem.
My solution was to add the ../ddeexec/* section in the registry on application startup and then remove them on application exit.
Not a very nice solution but it is easy to do, and it works.
I am suffering a serious problems. The problem is that when i enter billing information, select shipping method and press continue button then it goes to cart page. But Cart is not empty. It should go to payment method step. I am used magento 1.8.1.0 version. When i click on continue buttom my ajax is running . I get the following error in console
"NetworkError: 500 Internal Server Error - http://www.themeatboutique.com.au/shop/checkout/onepage/saveShippingMethod/"
All things are working fine before 4-5 days.
Finally I found about the problem. The problem is that $this is not working in setTemplate file. Not Sure why it is not working
So Can anyone please tell me the solution
In my experience, the most common cause of 500 Internal Server Error on a Magento page that was previously working is a minor typographical mistake that affects syntax enough to make the .php impossible to compile into op-code, therefore, impossible to render, therefore, impossible to serve to the browser.
On the checkout page, such an issue in any of the code that is collated into the standard onepage "pseudo-view" you're using could produce that result at that step. It sounds like all rendered well up to the step following shipping, so your syntax error is most likely in one or the other of those files that creates the view for those two steps, and is most likely in the one following the shipping method.
Look for the usual suspects, a single-quote / double-quote mismatch, a stray line of code missing a semi-colon, a nested array with mismatched parentheses, etc.
If it is none of these, check your /var/system.log and /var/exception.log files for clues.
It is almost always frustratingly simple when you find it.
Happy hunting!
Yesterday, the person in charge of adding content to our OrchardCMS website suddenly got this error when trying to access the Content section in the Dashboard and we can't add any new content any more.
I've imported a bacpac of the database in production and started locally debugging. When trying to access the Content an exception is thrown right here:
And, if we look in the database, the Orchard_Framework_ContentItemVersionRecord table contains a duplicated item with the same version Number, both are "latest version" and they both have the same ContentItemRecord_id.
My concern now is how should we fix this without causing any side effect somewhere else, since I don't fully understand how Orchard manages relations between items, parts, and versions.
Solution proposal:
It seems natural and obvious to manually update the "is latest version" of one of the items to false and increment the version number of the latest one.
Is this solution right or will I cause a side problem?
Have you experienced this before?
Do you know if this is caused by a wrong way of defining the model or something I can do to prevent this from happening again?
Quick answer: it is probably due to double clicking the publish button... Small tip and hack: hide publish button on click...
I remember that happened to me once before, it was ugly situation and a lot of debugging had to be done to find the cause.
The only fix I could find back then was to alter/edit/fix the db data manually.
I must ask
did that error happen once or does it happen all the time?
I am using my ccnet which is configured with the clear case
and everything is working fine as expected,but i am unable to see
anything in the "ViewProjectModificationHistory".whenever i click this
tab,i see a message which tells that :"No history Data found, make
sure you use the modificationHistory Publisher for this
project".Infact i had added under the tag.And to my
suprise,when i open this same link in the other persons system,it
opens well and fine and see all the modification history recorded.
So can anyone please tell me what could be this issue and how can it
be resolved?
Thanks and regards
Maddy
You should check your build history file. This will contain the XML data that feeds these reports. In particular, check the modifications/modification nodes to see if they are populated or not.
My guess is that the modifications are not there - so there may be nothing to display.
Another gotcha I have caught myself doing is not actually checking that there was in fact changes committed since the last time I built a project.