Using JEdit for AutoIt Development

I work with AutoIt today and as a JEdit user, I feel reluctant to install another Text Editor just for it. So, I searched around for JEdit-based solution. Some searching around later, got me this link. It is actually a frame from this site, I shortcut it here since it's not that obvious if you go from the main page.

It took time to follow all the instruction, even to the point I doubt whether this is all worth it :). Hopefully it will be integrated with JEdit's built-in plugin manager later for seamless installation. However, it works nicely in the end and my JEdit setup now very comfortable to work for the task.

Using Custom Action in Visual Studio 2005 Deployment Project (under Vista)

There are some quirk using Custom Action in Visual Studio 2005 and if your development machine is Vista you have even more trouble to sort. Here are what I faced recently :

• Unhelpful error message. See : "Windows Installer fails on Vista with 2869 error code.". In my case, I just run the resulting installer in an XP machine to get more informative message.
  
• When you add Custom Action for Commit phase you need to include your Custom Action Library to Install phase although you don't do anything on it e.g: override it. If you don't do this it you will have error can not save state or something. More about it here.

Thanks to google, the solutions are only one (or several) search away.

Using Directshow in .Net : DirectshowNet vs. C++/CLI

There are two usable option for using Directshow in .Net so far (excluding the abandoned-managed-directshow) :

1. Purely in .Net using DirectshowNet : code -> directshownet
   
2. Get a little bit dirty using C++/CLI : code -> c++/cli bridge-> directshow

Having tried both, I prefer using the second one for several reason :

1. You don't need to translate between what's on the directshow manual with what you need to write. On many cases you could just paste and code many boiler plate code as is and it just run. Using directshownet you have to do some mental gymnastic to do it.
   
2. Debugging would be more comfortable in native language.
   
3. You can hide the complexities of Directshow/COM exclusively in native code and have your managed code stay clean. You'll most likely end up with three layer modularisation : .net code -> c++/cli -> native c++ that access directshow. In the middle layer (c++/cli) you could provide your managed code with clean interfaces using native .net construct e.g: Properties, Event Handler.
   

However, the downside is quite obvious : you need to be comfortable with C++.

To sum up : You'll do better using C++/CLI when :

• You already familiar with C++
• Want to make application rapidly utilizing .Net

Although for those who still does not like to bother with C++/C quirks and overhead/headaches e.g: builds, linking, compilations, DirectshowNet route can provide more convinience with a "little" cost of translation and more "shady" debugging.

The better option from all these would be a .Net library that encapsulate Directshow in a more .Net-friendly way, not just a collection of "typedef"s. An even better one would be a much friendlier multimedia framework (assuming currently directshow's existing codecs and filters ported there too :) ).

Summarizing (Heavily) the Use of Event Handling Framework in .Net

I have been doing lots of code using callbacks recently and it happen to be in .Net (C#). I need some time to get used to the term, conventions and helpers that is available in .Net but in the end it is actually quite convenient with lots of predefined construct available.

Here's to sum things a little :

• For "raw" callback there's delegate. It's only a little higher than C's function pointer i.e: provide type checking.
• Above it there's event construct. It restricts delegate so the client can only add and remove itself to it but not others. Having that restriction it can now be viewed as broadcaster-subscriber model implementation (or signal-slot in qt term).
• Now, it gets more interesting : there are predefined Event Handling Framework that can be used so I can save some typing and maintenance. For typical purpose, you could use default non-generic version. What you need to do is declare the Event on the broadcaster :
  
  public event EventHandler SomethingHappen;
  
  and on the client, make the handling function based on the predefined argument pattern,
  
  private void OnPlayFinished(Object sender, EventArgs e) { ... do work... }
  
  and subscribe it somewhere :
  
  broadcasterObject.SomethingHappen += OnPlayFinished;
  
  This is what being used throughout WindowsForms-related code in VisualStudio that we could use for our own purpose too.

Doing callback-related code has already quite mind-occupying so useful help like this is very much welcome.

Get Current Position On Encoding in Directshow

When doing encoding in directshow, getting the current position (needed when you want to show progress of current encoding process) is not as obvious as for playing. I try to use the code from playing operation first i.e: get IMediaSeek interface and do GetDuration and GetCurrentPosition, but the progress is very inaccurate. The graphedit behave inaccurately also.

I found the solution later after some browsing around in Directshow help. To summarize, the solution/explanation :

IMediaSeek you got from Graph only accurate for playing operation. For file related e.g: on encoding operation, get IMediaSeek from AVIMux instead of the Graph.

The rest are the same with playing.