Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Thursday, September 3, 2009

Victory!

Zeep did indeed do what I wanted, and I found a site that hosts ASP.NET for free for 90 days, so I can now set my street cleaning days from my phone!

So if I have it set for the South side of the street (reminding me to move the car on Tuesdays and Fridays), my calendar looks like this:

Week from a Google calendar showing reminders to move the car on Tuesday and Friday

And then I go somewhere and when I come back I park on the North side. So I text "cleander n" to 88147, and the reminders jump to Mondays and Thursday, (excluding any day in the green holiday calendar):

Same week with reminders to move the car on Thursday, with none on Monday because of Labor Day

Zeep recognizes my phone number and uses the "cleander" string to route everything following it to my ASP.NET page in an HTTP POST request.

When the message gets to my site, the "n" or "s" populate the calendar with reminders on the appropriate days, an empty text clears the calendar completely (useful for going on vacation), and anything else will result in an error response.

I've saved "cleander n" and "cleander s" as message templates on my phone, so now any time I park it's just a few quick clicks.

Of course it will all fall apart in 90 days when my AspSpider account is deleted, but in the meantime maybe I'll be able to find some other free hosting option: all I need is to be able to run some sort of code in response to a POST request; the code is in C# right now, but it's short, and Google has APIs for Python and PHP and Java and whatnot as well, so I should be able to find something that works.

Update: Okay, Google's AppEngine will totally do what I need. I'll try it out tonight. It's fun and amusing to cobble together a baroque solution like this all to accomplish something that would take no effort at all if stupid T-Mobile would let me run a program on my phone in the first place. but also sort of depressing that I have to.

Update Deuce: This makes me feel a little better...apparently I'd have to do something similar on the Apple phone, as they don't provide a calendar API. Android does, but it's undocumented, though I would assume they make syncing with Google Calendars pretty easy so maybe it's less work. Palm gets it right.

Friday, July 24, 2009

Setup Error

I have been working on this stupid bug like all week: one of my programs would occaisionally pop up a window entitled "Setup Error," with the contents "Failed to load resources from resource file. Please check your Setup" and then disappear when the window was dismissed: no exceptions to catch, no other clue as to what might be wrong.

It's evidently a symptom that can arise under several different circumstances: I found several people who saw it when causing an infinite recursion, or when running an application on a machine with certain third-party anti-virus software installed. I didn't find anything that sounded like my circumstances, so I record them here in hopes that frustrated searchers might be helped along.

My setup and architecture were as follows:

  • .NET Framework 1.1;
  • One UI event handler hides the main form and creates another form, displayed in its own Get/Translate/Dispatch message loop until it's closed;
  • The new form creates a System.Windows.Forms timer;
  • At which point, certain calls (the two I found were System.Threading.Thread.Start() and the overloaded System.Xml.XmlDocument.Load() that takes a URI string; the one taking a TextReader worked fine) cause the "Setup Error" when made from the timer elapsed event handler.
Also, the "Setup Error" only occurred when running a Release build, either from Windows or from Visual Studio "Without Debugging."

I'm still not sure exactly what I was doing wrong, or whether I was encountering a bug in the framework. I refactored the code to get rid of my inner message loop and it seems to have fixed things, so I assume that the implementation of the forms timer somehow relies on its only being maintained by the built-in message loop...but in such a way that causes only certain other methods to fail? It's a mystery.

Friday, May 29, 2009

All Side Effect

Pretty sure this fails to conform to the intended use of properties:

        int _alarmEventCount = 0;
        public int alarm { set { _alarmEventCount += 1; } }

Not my code, but by a coworker who is good, so I'm sure there's a logical reason how it came about.

Friday, May 9, 2008

More 3D Graphics

Microsoft just released the "community preview" of the new version of their C# game development libraries, and it happens that someone has already done a demo of anaglyph stereo for it:

Screen capture of XNA anaglyph demo

Looks good! The cool thing about XNA is that you can use it to make Windows games, and then target the XBox (and with this version, the Zune) with the same codebase.

I think if I mess around with any of this stuff in the future I'll still be sticking with Axiom, because targeting Mac and Linux is more practically useful than targeting the XBox and Zune. And an XNA render platform for Axiom is already under development in any case.

Wednesday, April 30, 2008

3D Graphics

I've been dicking around with the Axiom 3D engine in my free time for a couple days. It's a C# port of OGRE, and someone had figured out how to do a red/cyan anaglyph display in OGRE, so I was trying to get that to work in Axiom:

Anaglyph robot rendering

I had to make some changes to some of Thieum's original material scripts to account for features that aren't supported yet in the current Axiom alpha release, but it seems to basically work.

I'll be sure to let people know when I start producing the next Björk video.

Wednesday, April 9, 2008

Nerd Party

I wrote this C# class for reading INI files on my own time and I think it's cool so I'm posting it up. It uses reflection to populate the fields and properties in a class with values from an INI file.

If you want to read a Windows INI file that looks like this,
;test.ini

[Shape]
Width=100

[Name]
First=John
Last=Williams
,
then you just make a subclass like this,
class TestIni : IniFile
{
   public TestIni() : base("test.ini") { }

   public class ShapeSection
   {
      public int Width = 10;
   }

   public readonly ShapeSection Shape = new ShapeSection();

   public class NameSection
   {
      public string First = "";
      public string Last = "";
   }

   public readonly NameSection Name = new NameSection();
}
,
and then you can use it like this:
TestIni ini = new TestIni();
Console.WriteLine("{0}, {1}", ini.Shape.Width, ini.Name.First);
.
It's cool because the structure of the subclass mirrors the structure of the INI file it represents, with a member class for each section containing a field or property for each key.

There are a lot of INI access utility classes out there (thanks to Microsoft not providing any in the Framework), but all the ones I saw used things like dictionaries to look up values by string. I think the reflection approach makes for neater client code.

Potential improvements include the ability to specify alternate names for member data, allowing you to access key or section names that are not valid C# identifiers; and the ability to write out changes to the member data to the INI file.