I've looked at so many articles in the past year without finding an answer, I'm starting to go crazy...
I do a lot of application support and use the Event Viewer on a regular basis. On any machine but mine, when I look at an event with Event ID 0, the "data" part of that entry is shown in the General tab of the viewer. This is the default behavior that I like. On my laptop, however, for about a year now, Event ID 0 shows as "The operation completed successfully." I no longer see the "data" part of the event in the General section of the window.
Example of the annoying message
The only thing I can think of, is that I added a custom description (or definition) for Event ID 0. But frankly, I don't know how I did it, if that is the case. I want to go back to seeing the "data" in there, rather than this useless message.
Does anyone know how to fix this?
While not a "fix" to the problem, I have what may be a workaround for you.
First, I can confirm that I have experienced it also--and it's been on MORE than one computer. But it has been limited to only some apps ("sources", in event viewer parlance). So I am assuming it's THEIR doing rather than ours. Your situation may be different.
But second, and until you may find a better solution, I will note also that there may well BE a useful message for you to see. If you click on the Details tab above that message, the "friendly view" of the details will readily show what the "real" message is that underlies that log entry.
See this screenshot showing a Postgres startup message that was hidden under such an "operation completed successfully" log entry.
I have seen it and other apps/sources work this way for such startup status messages, failures, errors, and more.
Like you, I lament that we should have to know to do that. It feels to me like the folks creating the code that create the event log entry are making some choice that leads to this behavior. At least now I know that I can SEE the info they are trying to share, albeit via what seems a poor choice.
Related
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.
At certain times in its operation, Glimpse 1.8.2 POSTs to api.mixpanel.com.
What is it sending?
How can I stop this from happening?
How can I opt out?
From "avanderhoorn" at https://groups.google.com/forum/#!searchin/getglimpse-dev/mixpanel/getglimpse-dev/7WgpX_Menz4/tnqJBwt20ZgJ:
I'm sorry this caught you off guard, that is not our intension.
This is to be expected and went out with the last release - http://blog.getglimpse.com/2014/02/04/glimpse-1-8-2-released/ (see Glimpse Insights support). Its a part of an effort to try and make better decisions for choices we make -http://blog.getglimpse.com/2014/01/22/getting-greater-insights-into-glimpse/.
It is a part of core but when switched off, its a complete removal (from the blog post):
If you do opt-out, there will be no traces of Insights in your code base. Insights was designed not simply to be a switch on or off, but to be a complete removal. Meaning no traces of the Insights code will remain if you choose to opt out.
The information being gathered can be viewed if you have a look at local storage. If you want a better view than that, you can get the client repo - https://github.com/glimpse/glimpse.client/ - and running the test client - https://github.com/Glimpse/Glimpse.Client/blob/master/test/Client.html. Once you have that open you will see a tab called "Insights" on the right which shows the data as its being collected. Also, if you want to see the source code involved, its isolated to this one file - here is the specific code that captures the events https://github.com/Glimpse/Glimpse.Client/blob/master/source/glimpse.insight.js#L345-L520.
You are right about the fact that it should be on the site. We have a new site coming out soon and its noted there. Its an oversight and the fact that we have been focusing on the new stuff. In response to an earlier question - https://twitter.com/greensky/status/431491507590160384 - we have also updated the Glimpse.axd to have the code required to opt-out. This will go out with the next release.
As an action item on this, I'll update the config help page of the current website to make sure the same information thats in the post will be noted there. Also I would like your feedback if there is anything else you think we can do to help. For the sake of completeness, the following is the opt-out code which goes in your web.config:
<glimpse>
<clientScripts>
<ignoredTypes>
<add type="Glimpse.Core.ClientScript.Insight, Glimpse.Core"/>
</ignoredTypes>
</clientScripts>
</glimpse>
Lastly, as we get time, we will be making the data collected publicly available. If this is something you are interested in helping out with, we could sure use the help. We believe that information like this will not only help us make better decisions, but help the community inform us what they want beyond what we here from the occasional person on twitter or at conferences.
Let us know what you think.
In a production application that I have developed sometimes I get an error saying .getDocument() is null. I have added checks in my code that traps an error if this happens. And the strange thing is that the XSPDocument seams to be OK.
Any other ideas how to debug the cause of this?
========================================================
Edit
The lower parts of the application is a simple database, create an assignment it gets status new
change the status to ongoing thru a button. Add information in text, date and numberfields, no Richtext, no attachments.
The user can switch to another xpage to send this document is an pdf attachment in an email.
The user can save the document as a draft
When they are done the click on an approve button and this button will set the status to approved. Save the document and send it as an pdf to an email adress
The problem ocurrs both on the Save button and on the approve button.
.getDocument from the xsp document is null the xspdocument.getNoteID return an ID
I can do replaceitemvalue on the xsp document.
It never happens on new documents only existing what I have seen
It feels like the comment from David that the backend doc is dropped/recycled
we experienced the same getDocument() problem recently. Finally we found a root cause: two different XPages were loaded simultaneously via iFrames. One of those XPages produced run-time error randomly, in 25% of cases. A sort of conflict in JSF model in context of single session.
solution: viewState="nostate"
not sure if it helps in your case, but this option resolved a lot of problems in our applications. It was introduced in 8.5.3. And it should be especially useful for so called XAgents.
Hard to give a hint without knowing more about everything else, but I remember having seen this as well. Just a few ideas:
Is XSPDocument.getNoteID() pointing to a valid Document if this happens?
Is it maybe pointing to a different doc than what you expected?
Could there be some kind of dynamic change of datasources going on?
Maybe some kind of timeout so that the server all of a sudden forgot who you are (in rare cases this happens to me)?
Lothar/edcom
It would be helpful to have a few more details. I assume that the document has previously been saved and it's not a new note?
You're not trying to put the actual document object inside a scoped variable are you? That would be bad as that would be pretty toxic. Without knowing more I would think this could be the case. The backend document has been garbage collected.
i need some help related to masked field in web form. Syntax of phone field is (___)___-_____, if i execute this code in ruby shell
browser.text_field(:id => 'txtphone').set '7893457889'
... nothing has been added in the phone field.
then i find this solution in one blog, someone said first unmask this field using this code.
browser.text_field(:id,'txtphone').fire_event("unmask")
then write the above code again.
browser.text_field(:id => 'txtphone').set '7893457889'
but still nothing has happened. kindly help me out...am i doing right or still there is a mistake.
If you could provide some sample of the page HTML it will be easier to give you an answer more likely to work.
Given what you have provided us to work from, we have to go with the normal way that such masked input fields typically work and go from there. Usually pages with this kind of thing are calling a javascript function which is triggered by a specific event. Most often this is an event such as onchange but it may be something like keypress or any other even that happens when a normal user types or pasts text into the cell.
You likely need to experiment with using the '.fire_event' method to fire the proper javascript event, or if that fails entirely making a direct call to execute the proper script
When doing this do not confuse the name of a script such as 'applymask' or somesuch with the javascript event which causes that script to be invoked.
The answers to this question How to find out which JavaScript events fired? include some good information on how to use firebug or the chrome developer tools to figure out what events are being fired when you interact with an object on the browser screen.
Update: instead of responding here to indicate if this answer was of any use the OP reposted their question here Masked Text Box issue and by digging around on the vendor's demo site (since that time he actually had posted some of the HTML when we asked for it) I was able to find a solution using watir-webdriver that worked for him.
An obscure puzzle, but it's driving me absolutely nuts:
I'm creating a custom Information Management Policy in MOSS. I've implemented IPolicyFeature, and my policy feature happily registers itself by configuring a new SPItemEventReceiver. All new items in my library fire the events as they should, and it all works fine.
IPolicyFeature also has a method ProcessListItem, which is supposed to retroactively apply the policy to items that were already in the library (at least, it's supposed to do that for as long as it keeps returning true). Except it doesn't. It only applies the policy to the first item in the library, and I have absolutely no idea why.
It doesn't seem to be throwing an exception, and it really does return true from processing that first item, and I can't think what else to look at. Anyone?
Edit: Cory's answer, below, set me on the right track. Something else was indeed failing -- I didn't find out what, since my windbg-fu isn't what it should be, but I suspect it was something like "modifying a collection while it's being iterated over". My code was modifying the SPListItem that's passed into ProcessListItem, and then calling SystemUpdate on it; as soon as I changed the code so that it created its own variable (pointing at the exact same SPListItem) and used that, the problem went away...
There's only a couple of things I can think of to try. First, are you developing on the box where you might be able to use Visual Studio to debug? So just stepping through it.
Assuming that's not the case - what I'd do is fire up WinDBG and attach it to the process just before I registered the policy. Turn on first chance exceptions so that it breaks whenever they occur. you can do that by issuing the command "sxe clr" once it is broken in. Here's a little more info about WinDBG:
http://blogs.msdn.com/tess/archive/2008/06/05/setting-net-breakpoints-in-windbg-for-applications-that-crash-on-startup.aspx
What I'd do is then watch for First Chance exceptions to be thrown, and do a !PrintException to see what is going on. My guess is that there is an exception being thrown somewhere that is causing the app to stop processing the other items.
What does the logic look like for your ProcessListItem? Have you tried just doing a return true to make sure it works?
Some nice ideas there, thanks. The Visual Studio debugger wasn't showing an exception (and I've wrapped everything in try/catch blocks just in case), but I hadn't thought of trying Windbg...