May 2004 - Posts
FREE XDN Professional for .NET Bloggers during May 2004
Mike Schinkel, president of Xtras.Net, made an offer on his personal blog of a free XDN Professional membership (http://www.xtras.net/xdn) during the month of May 2004 for anyone that blogs about .NET frequently. If you are a .NET blogger, see Mike's post for how to get your free XDN membership.
We are handling the Validating event for a control. If a conditional test fails in this event handler, we set CancelEventArgs = True and call SetError on ErrorProvider :
If txtBox.Text.Trim = String.Empty Then
Me.ReviewErrorProvider.SetError(DirectCast(sender,
txtBox), "Required Field")
e.Cancel = True
There is a button on the same form as the control. Call this buttonA. When clicking on buttonA after setting CancelEventArgs = True in txtBox's validating handler, the Click Event fires for buttonA. Since we called e.Cancel = True, this event should not fire.
Now, if we add a breakpoint on the call to CancelEventArgs = True in txtBox's validating handler, buttonA's click event is blocked (the event does not fire).
So, what is it about the breakpoint that makes this work?
This has been reported as a bug to Microsoft.
Per this article:
http://msdn.microsoft.com/netframework/using/building/windows/analystreports
/smartclient.aspx
"Use the Assembly.LoadFrom method from the System.Reflection class:
This is helpful in two scenarios. In the first, the initial executable was
launched via a URL (see #1 above), but now needs to access DLLs that are
located in a different directory on the server or on a different Web server
altogether. In the second, more common scenario, the application is
architected so that there is a small, lightweight executable installed on
the client machine. This executable need not contain much in the way of core
logic. Ideally, it just references the DLLs it needs, which reside out on a
remote Web server and which supply all of the necessary application logic.
Having the executable installed on the client machine in this way means that
the user will have an icon with which to launch the application. Again,
installing the executable could be as easy as copying it onto your user's
local disk—no registration required. The code samples below give guidance on
how to use Assembly.LoadFrom: "
This is exactly what we do.
I am seeing cases though, when a assembly on the web server is modified,
where the .net client is not downloading the modified assembly. The IIS Log
shows a return code of 204, no changes.
I assume something is failing with the If-Modified-Since check. We are not
using IE's download cache as we do not put an executable out on our remote
Web server, and then let the user navigate to it by entering the URL in
Microsoft Internet Explorer.
We distribute a lightweight exe, as described above, that calls
Assembly.LoadFrom loading the assemblies from our web server.
When an assembly on the web server is modified, the only way I can get the
client to download it is to clear out the download cache. So, it makes me
wonder if .NET's download cache is not checking the If_Modified_Since header
and\or you have to go through IE to get this to work.
This is a reminder that the next meeting of the Richmond.NET User Group will take place tomorrow, May 20, 2004, at 6:30PM. Once again, the meeting will be held at Fahrenheit Technology in Innsbrook.
Geoff Snowman (blogs.msdn.com/gsnowman), who is the Microsoft Mid-Atlantic Developer Community Champion, will be presenting a talk about the new ASP.NET 2.0 framework. This should be an extremely exciting and informative presentation.
I really hope to see everyone there. If you have any questions or comments, please feel free to contact me.
OK, I officially dislike this feature.
I have a GroupBox that has labels and textboxes in it.
I am trying to set the tab order for the labels and textboxes with this
'wizard' thing.
4.3.0.0.1, 4.3.0.0.2, 4.3.0.0.3, etc....
All the way up to 4.3.0.0.14.
Then, when trying to set the next control to 4.3.0.0.15, it keeps setting it
to 4.3.0.15. Now, this would be OK except there is another control with
4.3.0.0.17. I need the 4.3.0.15 to go to 4.3.0.0.16. There is no way to do
this though with this wizard thing. If I manually set the tabindex from 0
to 25 in the properties window, then look at the wizard again, same thing.
So, when tabbing, after the 4.3.0.0.14 control, it tabs to the 4.3.0.0.17
control, when I need it to tab to the 4.3.0.15 control. There is no way I
can see to get this wizard to change the 4.3.0.15 control to 4.3.0.0.15
though.
The only way to 'fix' this is to delete and re-add the controls. What a pain.
This is an interesting read on writing wrapper classes for sprocs:
http://msdn.microsoft.com/data/default.aspx?pull=/library/en-us/dndotnet/html/autousa2.asp
I am not using it, but I may in the future.
I have been testing with this control and I have discovered what i think is a bug.
Drop one on a form. Set the MinValue to 0 and the MaxValue to 10.
Run and enter 11 into the control with the keyboard.
The control lets you enter 11 and actually displays 11.
I handled the key down on the control to see whats going on. I get this exception:
Exception Type: System.ArgumentException
Message: '10' is not a valid value for 'Value'. 'Value' should be between 'Minimum' and 'Maximum'.
When looking at the Value property and 11 has been keyed in.
So, we can limit user input with the click and scroll, but not through the keyboard? Why even provide a Min and max Value then?
Who was watching the twins? Chandelor, Monica, Joey? Nope, they were all in Joey's appt. I think the producers of Friends missed that one last night.
After who knows how many hours of 'why is this not working', I have finally figured this out. I hope my pain will lesson yours.
We were using Output params when we needed the sproc (insert or update) to return data to us. Due to some new requirements, we now need to fetch the entire record that was either inserted or updated.
So, I started on this rewrite journey last week. I picked two tables to test with, both doing update and inserts. I tweaked the sprocs to do a Select at the end and no longer return output params. I updated our DAL setting the Command's UpdateRowSource to FirstReturnedRecord.
I tested the insert and update sprocs in Query Analyzer and all looked good. The record was selected after the insert|update and I could see it in QA.
The problem, I never saw the record back in the .net client. I tweaked, retweaked, tested, debugged, pulled hair, yelled, kicked and then screamed. The scream finally made me realize the problem.
The beginning of all of our insert and update sprocs do 1+ Selects preparing for the insert|update. The problem with this? The select returns a result set. So, the FirstRetrunedrecord is the Select I am not interested in. I commented out all of these Selects, and viola, the .net client now has the record selected at the end of the insert|update.
More Posts