Ivan Krivyakov's Blog

I am discovering for myself the world of RSS, ATOM, and blog feed aggregators. I tried to find out what’s the difference between RSS and ATOM (here is a good starting point), and it looks like one of the differences is in the date format.

The older date format is RFC-822. It was adopted in 1982 and it has only two digits for the year part. Indeed, in 1982 the 21st century seemed like a very distant future. I do remember that feeling

The newer date format is RFC-3399, that was adopted as late as 2002. It specifies for digits for the year and reinforces the mandatory specification of the time zone, although many existing applications don’t do it. This is how the RFC authors justify their decision:

Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet.

In other words, gentlemen, wherever you live, keep in mind that you are not the center of the Universe. Approximately 23/24 of the globe has different local time! If you forget this, your interoperability will suffer. Be humble and specify your time zone.

Someone I could not refuse asked me to “take a look” at some Excel macros written in Visual Basic For Applications (VBA), which is a limited version of VB6 running inside Excel.

Well, of course I found a fair share of cut-and-paste and inefficient code looking for things it has already found again and again. This is not the point. Of course there is verbose syntax, pesky Set keyword, lack of across-the-board code verification, et cetera. Some of these are painful, but this is not the point.

I hate VB6 the most for the lack of proper data structures and algorithms.
[read more...]

It turns out that emissive material is quite a tricky fellow. Petzold’s book warns not to use EmissiveMaterial by itself, and always combine it with a diffuse material, which may be black. Otherwise, “the results are not satisfactory”. I found out firsthand what “not satisfactory” results may look like.

It turns out that behavior of “Emissive-only” material is not consistent for different shapes. Furthermore, if you combine diffuse material with emissive material, the diffuse material should come first, or else it negates effect of the emissive material. I suspect some very sloppy code inside WPF 3D, or maybe there is some hidden very important reason why it is what it is.

I wrote a little application that demonstrates the issue on various shapes. Here’s the summary of the results:

Note the inconsistency: a cube with emissive front and diffuse back is visible, while the triangle is not. The right thing to do is to define the material as a group having a diffuse and an emissive component, with the diffuse component always coming first.

I also have reasons to believe that Emissive-only sphere is visible, but is transparent: the objects behind it will show through. However, I am not sure whether this is an artifact of a particular sphere implementation, a particular scene, or a property of complex emissive bodies in general.

Back in the days of a now dormant Internet startup, we ran into an issue of how to dynamically add new objects (Flash or otherwise) to your page. If you simply do document.write() with some <object> tags in it, it does not work. The browser refuses to interpret new object tags.

However, there is a twist. It turns out you can add new iframes in JavaScript. You, a seasoned web developer, probably new it for years, but I discovered it by accident while trying to fight weird behavior of one of the popular social networks. Anyhow, you can add iframes dynamically, and these iframes may contain flash movies.

Here’s is an example that I wrote using a little PHP. Enjoy! If this sounds very trivial, I am sorry, us mere mortals sometimes have their ‘aha’ moments they do enjoy

This is not as easy as it might have been. There is no Visible property on ModelVisual3D or GeometryModel3D. Approaches considered in this discussion on the Microsoft site include making material brushes transparent or having a transform on the object moving it out of the way.

Fiddling with brushes leads to problems. First, base Material class does not expose the Brush property, so you must hunt for a concrete material such as DiffuseMaterial to get the actual brush. Second, the poster reports issues with objects other than the intended object getting partially invisible, etc.

The approach with transforms “to nowhere” seems more attractive, but it kinda reminds me of the days when people put windows at “large” negative coordinates (say -1000,-1000) to make them “invisible”. It worked fine for a while, but turned out quite ugly when 1200×1024 double-monitor setups became common. If you make your right monitor a primary, the left monitor gets negative coordinates, and you suddenly see all those windows crowded in the bottom of your screen.

It looks like “C# future” forum is not monitored, or everyone is on vacation. My post from August 27 is still without replly

I received a response to my question on the Microsoft WPF forum.

Will investigate and report the results here.

Every day when I open my solution in Visual Studio I get this message box:

After that Visual Studio checks out my solution file and a number of project files, does not change a thing in them, and the next time I open the solution I am told the same story again. It does not matter whether I undo changes or check them in – the project files on disk are identical to those in source control anyway.

Today I have finally got to investigate what is wrong with my solution. It turns out that I committed a thought-crime of putting some of the projects in a different directory tree. Well, it was actually not me who did that, but it does not matter. In a nutshell, I have the following directory tree

Root\
  Stuff\
      ProjA\
         proja.csproj
      ProjB\
         projb.csrpoj
   Solution\
       ProjC\
          projc.csproj
       solution.sln

It looks like when I open the solution, Visual Studio notices that it lives in Root\Solution, while projects ProjA and ProjB live in Root\Stuff. This is not allowed and must be fixed immediately. So, it checks out the solution file and project files for ProjA and ProjB. Then it realizes there is really nothing it can do and does not change the files. It leaves ProjC alone, since it is a law-abiding citizen sitting in its proper cell.

Source control bindings in Visual Studio always were a nightmare, and after 10 years they still can’t get it right. The funny thing about this situation is that all other source control operations work just fine – I can check out and check in files in all projects, compare for differences, and the like. But Visual Studio will still nag me every time I open the solution, because I have violated THE LAW and had an audacity to use projects from another directory tree.

In other words, they can handle it perfectly, but they still complain, in some indirect form, that I don’t follow the rules and insist on pointlessly checking out my files. Not cool.

It is not a big deal, but still unpleasant. It is not possible to do something like

<TextBlock Text=”Speed: {Binding Path=Speed} mph” />

The text in the squiggles appears verbatim on screen, the binding does not occur. Instead, one needs to write

<TextBlock>Speed: <TextBlock Text=”{Binding Path=Speed}” /> mph</TextBlock>

This requires significant amount of extra typing when writing, and creates serious clutter when reading. Not a big deal, but disappointing. A better solution would be to parse expressions like this and do the bindings. Of course, there will be implications: if one really wants a squiggle, they will have to escape it, just like in String.Format. Also, when looking for bindings and other extensions, WPF will have to scan the whole text instead of just checking the first character. I am not sure how serious this is, but it does not sound very ominous. I suspect WPF authors just did not have time to implement this advanced parsing.