error message: form1.execValidate is not a function. but this has worked fine for years!
Last week the client (large bank) rolled out a new version of Adobe Reader XI 11.0.21. Perhaps registry keys were changed as well - don't know.
So now all livecycle forms are crashing. Below is one error message seen on the console followed by the crash.
The code being used has been executed 10K+ times over ~5 years, over roughly 5 different forms over many versions.
form1.FirstPage.sfBody.sfSectionB.sfEnder.SendReferral::click - (JavaScript, client)
var res = form1.execValidate(); // does form validation, if all good returns true
if (res) {
cLookFeel.fMailTo(event.target);
}
(Code is attached to the click method on a button, cLookFeel is the name of my code block.)
And strangely - Reader then seems to (often) crash. Go figure.
followed by a crash:
Okay, turns out it's a known bug by Adobe on 11.0.21. They've issued a fix.
https://helpx.adobe.com/acrobat/release-note/acrobat-dc-august-11-2017.html
Related
In a large application using X11 I recently switched from one thread per window to single thread serving all windows.
Now the problem is that clicking the window-close button causes all windows to disappear.
I know about the option to disable the window-manager's handling completely (XSetWMProtocols) but I don't want to do that because I would need to implement my own window-decoration, -resize...
I am setting callbacks with XSetErrorHandler and XSetIOErrorHandler,
Previously only the single window of a thead disappeared and I used above-mentioned callbacks to do a long-jump, properly cleaning resources, then ending the thread. The other windows/threads continued running.
However those callbacks are not even reached now:
I have a breakpoint in those callbacks and on _XIOError but at that point all windows have disappeared already.
#0 0x00007ffff7a62300 in _XIOError () from /lib/x86_64-linux-gnu/libX11.so.6.3.0
#1 0x00007ffff7a5fa0d in _XEventsQueued () from /lib/x86_64-linux-gnu/libX11.so.6.3.0
#2 0x00007ffff7a51211 in XPending () from /lib/x86_64-linux-gnu/libX11.so.6.3.0
#3 0x00005555555dcf54 in xwin4gRunI (T=0x7ffff7b832e8, Xwin4g=0x7ffff7b831b0) at ../xwin4/xwin4.c:257
From _XEventsQueued's source:
while((response = poll_for_response(dpy)))
handle_response(dpy, response, False);
if(xcb_connection_has_error(dpy->xcb->connection)) {
_XIOError(dpy);
return 0;
}
I have libx11-dev and libx11-xcb-dev installed but I guess it is not being used:
(gdb) f 1
#1 0x00007ffff7a5fa0d in _XEventsQueued () from /lib/x86_64-linux-gnu/libX11.so.6.3.0
(gdb) p response
No symbol "response" in current context.
So I took a look into poll_for_response: nothing that looked like window-unmap/destroy.
And into handle_response. It has:
case X_Error:
handle_error(...)...
A breakpoint in handle_error is not reached. But that could be due to it failing to use the libx11-xcb-dev debug-build.
It is possible that I forgot to move something from the giant old part of code to the less-giant new part of the code. Is there some XSetWMProtocols needed to let the above-mentioned callbacks be called before the windows disappear?
After two more hours of searching I found that indeed another XSetWMProtocols call was needed. For those who run into the same problem: use it with WM_DELETE_WINDOW.
I am trying to use a Microsoft demo project which shows how to do ETW event tracing in WPF as a basis for some specific profiling I want to do in an app I'm developing.
Compiled as is, the demo works fine. However, change the target framework from .Net 3.5 to .Net 4, and it breaks. Clearly there is some significant change between the framework versions.
The question is what changed, and (more importantly) is it possible to fix the demo?
My investigation so far
Adding a Debug.WriteLine to FpsEventConsumer.EtwEventCallback I see that in framework 4 either no events arrive or two events arrive, both with Header.Guid of 68fdd900-4a3e-11d1-84f4-0000f80464e3; one with Header.Class.Type of UCE_GLASS_START and the other with UCE_GLYPHRUN_START. Note that I also observe these events, among many others, when testing under framework 3.5.
By digging around in referencesource.microsoft.com I discovered that MS.Utility.EventTrace's static field EventProvider of type MS.Utility.TraceProvider controls what gets sent to ETW. Using reflection to access the event provider (since it's non-public) I observe that in 3.5 it starts with everything enabled (_enabled is true, _flags is 2147483647, _level is 5); and in 4 it starts with everything disabled (_enabled is false, _keywords is 0, and _level is 0). But changing those values with reflection doesn't seem to help the situation much. At best, on a very rare occasion I get a few events emitted before the UCE_ ones mentioned above.
By placing a WriteLine in TraceConsumer.ProcessTrace as follows, I observe that the p/invoked call continues to block, so the problem isn't that the trace is being interrupted.
ErrorCode errorCode = UnsafeEventTrace.ProcessTrace(handleArray, handleArray.Length,
(FILETIME)startTime, (FILETIME)endTime);
+ System.Diagnostics.Debug.WriteLine("ProcessTrace: " + errorCode);
if (errorCode != ERROR.SUCCESS)
{
errorCode.OutputErrorMessage("TraceConsumer.ProcessTrace");
}
It turns out that the answer was there all along in one of the referencesource files I looked at:
/// ...
/// TreatAsSafe: it generates the GUID that is passed into the TraceProvider
/// WPF versions prior to 4.0 used provider guid: {a42c77db-874f-422e-9b44-6d89fe2bd3e5}
///</SecurityNote>
[SecurityCritical, SecurityTreatAsSafe]
static EventTrace()
{
Guid providerGuid = new Guid("E13B77A8-14B6-11DE-8069-001B212B5009");
...
The following simple patch to Sample.RunTrace causes events to start flowing (although they no longer include the particular event which the demo uses for the FPS).
- m_traceSession = TraceController.WpfController;
+ m_traceSession = typeof(System.Windows.Rect).Assembly.GetName().Version.Major == 3
+ ? TraceController.WpfController
+ : TraceController.GetController(new Guid("E13B77A8-14B6-11DE-8069-001B212B5009"), "WPF");
When I attempt to run the line:
MyDBContext.Database.Log = Console.Write
The compiler smiles and tells me I don't know what I am doing...
The app won't compile because of the line and the error on that line is:
Overload resolution failed because no accessible Write accepts this number of arguments.
That makes sense. 'Console.Write' returns nothing and I am setting it equal to a System.Action(Of String)
This just seems kind of half baked.
I tried numerous ways to fix it including delegates, and some of the other 'new possibilities' moving this off the Context is supposed to offer but still no dice.
What am I missing? Is it something that was changed at the last minute?
I have two large edmx files (one connects to SQL Server and the other to Oracle) in the solution and all of that is working great.
Here are my version numbers if that can help.
EntityFramework 6.0.0.0 (folder is ...\EntityFramework.6.1.3\lib\net45\EntityFramework.dll)
EntityFramework.SqlServer 6.0.0.0 (folder is ...\EntityFramework.6.1.3\lib\net45\EntityFramework.dll)
Oracle.ManagedDataAccess.EntityFramework 6.121.2.0
I have a tool I created that lets me paste the output of the L2S 'mycontext.log' into it and it then parses it and creates SSMS ready SQL with variables... it has been incredibly useful. This has been one of my favorite features of L2S.
Please help me understand why this isn't working.
Thanks in advance.
This technique works for me:
public override int SaveChanges()
{
SetIStateInfo();
#if DEBUG
Database.Log = s => Debug.WriteLine(s);
#endif
return base.SaveChanges();
}
http://blogs.msdn.com/b/mpeder/archive/2014/06/16/how-to-see-the-actual-sql-query-generated-by-entity-framework.aspx
Well, the answer was to research the Action(T) Delegate which showed me how to do it.
#If DEBUG Then
myctx.Database.Log = AddressOf Console.Write
#End If
Just needed the AddressOf and I was back in business.
I've been having this issue for a while now an I just cant work past it anymore. I use to just recreate the project but now that solution no longer works for me either and i've had no luck with google at all.
I have a silverlight 5 website with a WCF service. Basically what happens is I'll have a piece of code i need to debug e.g.
using (var connection = new SqlConnection(AccessCardConnection))
{
connection.Open();
var command = connection.CreateCommand();
command.CommandType = CommandType.StoredProcedure;
command.CommandText = "GetAccessCardTimes";
command.CommandTimeout = 300;
command.Parameters.AddWithValue("#EmployeeName", fullName);
command.Parameters.AddWithValue("#FirstDate", firstDate);
command.Parameters.AddWithValue("#LastDate", lastDate);
var accessCardReader = command.ExecuteReader();
while (accessCardReader.Read())
{
var time = TimeSpan.Parse(accessCardReader["TotalOnSiteTime"].ToString());
duration += time;
}
return (duration.TotalHours);
}
However once the first break point hits its anybodies guess which line it will jump to.. It doesnt follow any kind of logical order it, if i set a break point on connection.Open() for example it may jump back into the connection intialization then back down again and jump any which way it pleases, up, down, stay on the same line etc. Jumping in and out of methods as it seems to have no regard for what its doing.
None of the solutions I've found online have helped:
Why do my debugger randomly jump out of debug mode? (Fix is for visual studio 2008)
Visual Studio 2010 Debugger jumps around (Deleting the /bin and /obj files to regenerate the symbols didnt help)
Please can someone give me a hint as to what it may be I cant work like this :(
Thanks for your assistance!
Sounds like you have multiple calls hitting the service. WCF spawns new worker threads for each request so what you are seeing is the debugger "jumping" from thread to thread.
We're migrating SQL to Azure. Our DAL is Entity Framework 4.x based. We're wanting to use the Transient Fault Handling Block to add retry logic for SQL Azure.
Overall, we're looking for the best 80/20 rule (or maybe more of a 95/5 but you get the point) - we're not looking to spend weeks refactoring/rewriting code (there's a LOT of it). I'm fine re-implementing our DAL's framework but not all of the code written and generated against it anymore than we have to since this is already here only to address a minority case. Mitigation >>> elimination of this edge case for us.
Looking at the possible options explained here at MSDN, it seems Case #3 there is the "quickest" to implement, but only at first glance. Upon pondering this solution a bit, it struck me that we might have problems with connection management since this circumvent's Entity Framework's built-in processes for managing connections (i.e. always closing them). It seems to me that the "solution" is to make sure 100% of our Contexts that we instantiate use Using blocks, but with our architecture, this would be difficult.
So my question: Going with Case #3 from that link, are hanging connections a problem or is there some magic somewhere that's going on that I don't know about?
I've done some experimenting and it turns out that this brings us back to the old "managing connections" situation we're used to from the past, only this time the connections are abstracted away from us a bit and we must now "manage Contexts" similarly.
Let's say we have the following OnContextCreated implementation:
private void OnContextCreated()
{
const int maxRetries = 4;
const int initialDelayInMilliseconds = 100;
const int maxDelayInMilliseconds = 5000;
const int deltaBackoffInMilliseconds = initialDelayInMilliseconds;
var policy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(maxRetries,
TimeSpan.FromMilliseconds(initialDelayInMilliseconds),
TimeSpan.FromMilliseconds(maxDelayInMilliseconds),
TimeSpan.FromMilliseconds(deltaBackoffInMilliseconds));
policy.ExecuteAction(() =>
{
try
{
Connection.Open();
var storeConnection = (SqlConnection) ((EntityConnection) Connection).StoreConnection;
new SqlCommand("declare #i int", storeConnection).ExecuteNonQuery();
//Connection.Close();
// throw new ApplicationException("Test only");
}
catch (Exception e)
{
Connection.Close();
Trace.TraceWarning("Attempted to open connection but failed: " + e.Message);
throw;
}
}
);
}
In this scenario, we forcibly open the Connection (which was the goal here). Because of this, the Context keeps it open across many calls. Because of that, we must tell the Context when to close the connection. Our primary mechanism for doing that is calling the Dispose method on the Context. So if we just allow garbage collection to clean up our contexts, then we allow connections to remain hanging open.
I tested this by toggling the comments on the Connection.Close() in the try block and running a bunch of unit tests against our database. Without calling Close, we jumped up to ~275-300 active connections (from SQL Server's perspective). By calling Close, that number hovered at ~12. I then reproduced with a small number of unit tests both with and without a using block for the Context and reproduced the same result (different numbers - I forget what they were).
I was using the following query to count my connections:
SELECT s.session_id, s.login_name, e.connection_id,
s.last_request_end_time, s.cpu_time,
e.connect_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_exec_connections AS e
ON s.session_id = e.session_id
WHERE login_name='myuser'
ORDER BY s.login_name
Conclusion: If you call Connection.Open() with this work-around to enable the Transient Fault Handling Block, then you MUST use using blocks for all contexts you work with, otherwise you will have problems (that with SQL Azure, will cause your database to be "throttled" and ultimately taken offline for hours!).
The problem with this approach is it only takes care of connection retries and not command retries.
If you use Entity Framework 6 (currently in alpha) then there is some new in-built support for transient retries with Azure SQL Database (with a little bit of configuration): http://entityframework.codeplex.com/wikipage?title=Connection%20Resiliency%20Spec
I've created a library which allows you to configure Entity Framework to retry using the Fault Handling block without needing to change every database call - generally you will only need to change your config file and possibly one or two lines of code.
This allows you to use it for Entity Framework or Linq To Sql.
https://github.com/robdmoore/ReliableDbProvider