Previously I thought this was not possible, since the ASP.NET postback involves POST-ing the all-encompassing ASP.NET form, but I am here to tell you, that it is indeed possible to do a postback to a new window or even a popup (created with window.open). In fact, it is surprisingly simple. All you really have to know is that the “target” attribute you know from anchors (links) works exactly the same way for forms!
Continue reading ASP.NET Postback to new Window or Popup
2011
You are browsing the site archives for 2011.
I needed to grab a paged list of Data from some Website and wanted to do it with a Browser Automation Tool.
There’s Telerik’s Free Testing Framework but that one needs to be installed (because it uses Plugins/Addons for the Browser) in order to run.
I found a very nice alternative: WatiN (or http://sourceforge.net/projects/watin if the other page is down)
It’s a simple Library which allows everything needed when automating webbrowsers.
The Microsoft SQL Server Management Studio (even v2008 R2) has problems with executing large SQL-files. To execute these files you need to use the sqlcmd Utility.
Sample usage:
sqlcmd -S myServer\instanceName -i -U loginname -P password C:\myScript.sql
That one recently cost me a couple of hours and quite a bit of nerves to figure out: In a 64bit Windows, if a 32bit process accesses the Registry, it actually interacts with a DIFFERENT registry than a 64bit process. This means that your 32bit compiled program potentially reads and writes different registry keys than the same program compiled for 64bit! I’m sure you can imagine how this might result in seemingly strange behavior if you don’t know that. Windows Registry FTW, right?
Since regedit.exe runs as a 64bit process, you can usually only see the 64bit registry, but what if you want to see/change 32bit entries? It turns out you can do that if you know how this registry redirection works. In every node in the (64bit) registry there CAN be a child node with the name “WOW6432Node” that contains the 32bit entries that override/amend the 64bit entries. The only WOW node that I could find in my registry was in HKLM\SOFTWARE, but the concept works for every other part of the registry.
Source: http://msdn.microsoft.com/en-us/library/aa384253%28v=vs.85%29.aspx
Those of you familiar with Linux systems should know the very helpful “which” command which can tell you where exactly an executable that is in your PATH is located. The good news is, that a very similar command exists in PowerShell
> get-command tf
If the TFS exectuable is in your path, this gives you output of the form.
CommandType Name Definition ----------- ---- ---------- Application TF.exe C:\Program Files\Microsoft Visual Studio 9.0\Com...
But that’s not very helpful, is it? I mean, a quite important part of the path is cut off for crying out loud. So how do you get the FULL path?
> get-command tf | format-list Name : TF.exe CommandType : Application Definition : C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe Extension : .exe Path : C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe ...
And there you go. It’s a bit more complicated than necessary, but at least it’s possible.
Today I’ve had an extremely interesting realization: the number, order and exact point in the page lifecycle at which HtmlMeta controls are added to the HTML head can have significant implications for your page. Especially if you have some sort of “transient” meta tags that are only added to the page when it is initially loaded, but not after a postback. When you call the
myHeadControl.Controls.Add(myHtmlMetaControl)
method, every control that doesn’t have a manually set ID will be assigned an automatic ID by its naming container (ctl00, ctl01, …). This doesn’t seem too bad until you realize that this means that the ID of your very important custom control can change from “…ctl08…” during initial page load to “…ctl04…” in a postback. And THAT is a problem. Because the way that the view state is restored to the control tree is directly through those control IDs. Actual results can vary from mismatched control values to view state exceptions and lots of other hard-to-trace problems.
Continue reading Prevent automatically generated IDs for controls
This is for now just a bucket with helpful resources:
- http://create.msdn.com/en-US/education/catalog/sample/primitives
- http://forums.create.msdn.com/forums/t/7414.aspx?PageIndex=4
- http://jtfeck.awardspace.com/
- http://www.bit-101.com/blog/?p=2832
- http://blogs.msdn.com/b/manders/archive/2007/01/07/lines-2d-thick-rounded-line-segments-for-xna-programs.aspx
Yesterday, I made my first multithreaded tests with XNA 4.0.
I started with my own WorkerThreadManager, a BlockingQueue and some WaitHandles to setup a Worker-Queue and Workers. The testproject was a an XNA-App just drawing circles and move them around (with collision detection on the walls). The first test was rather disappointing. I could run about 4x more circles in single-threaded mode than with multi-threaded approach.
After some profiling, I found that the BlockingQueuewas the bottleneck. I then found the class BlockingCollection from .Net 4.0. Using that one improved the speed quite a bit but still about 3x slower than the single-threaded one.
After some more research, I stumbled accross the brand-new System.Threading.Tasks Namespace with some quite interesting classes.
I could replace my whole ThreadManager with this little piece of code:
List<Agent> agentList = SomeHowGetSomeAgents();
Task[] tasks = new Task[agentList.Count];
for (int index = 0; index < agentList.Count; index++)
{
Agent agent = agentList[index];
Task t = Task.Factory.StartNew(() => DoSomeWork(agent));
tasks[index] = t;
}
Task.WaitAll(tasks);
Nice, eh. That further improved the speed but again, it’s still about 2x slower than the single-threaded one…
So I found one more class called Parallel.
With this class, the code now looks like:
List<Agent> agentList = SomeHowGetSomeAgents(); Parallel.ForEach(agentList, DoSomeWork);
That one finally runs faster than the single-threaded approach. Three times faster!
I might need to redo all those tests when the DoSomeWork is much more sophisticated. But for now, Parallel seems the way to go for simple Worker-Threads.
Recently I’ve noticed that a lot of my co-developers where I work don’t use a lot of tools beyond the usual VisualStudio / Notepad combo. I find that rather weird since personally I have spent a lot of time learning how to use certain tools because it makes life just that much easier. As I am pretty sure I have mentioned before, developers are supposed to be lazy. According to Larry Wall (the inventor of Perl) this is even one of the three most important virtues of a programmer – the other two being impatience and hubris. In this case I happen to agree with Larry, because the urge to avoid any kind of repetitive, mind-numbing task or do something with two clicks instead of three is what programming is all about.
I always forget how to Rollback a Changeset, so here’s the command to do it:
First, make sure you got the Team Foundation Server Power Tools installed.
Then execute the following command:
tfpt rollback /changeset:<changesetnumber> "<workspace>"
so for example:
tfpt rollback /changeset:48745 "C:\Workspaces\XXXComplete"