25.11.09

FCKEditor Image Browse

Often, instead of "hard coding" a html page I decide to allow site's owner to enter and change contents himself. FCKEditor is a great open source tool that allows for text (and not only!) editing much like desktop word processors. It also allows inserting images within the text.
Despite the capabilities the built-in file manager offers sometimes a custom file manager/file uploader is needed.
I develop ASP.NET sites so I needed a "bridge" between the HTML/javascript coded FCKEditor and the ASP.NET code.
First of all, however, I needed means to control whether the "Browse Server" button is displayed in the dialog.






















This property is set in fckconfig.js located in fckeditor folder. The property is
FCKConfig.ImageBrowser = true;
and is set to "true" by default.

More interesting is, nowever, to change what this button displays and therefore change the way images are accessed. One common way to store images is in MSSQL server in which case the default image browsing as well image uploading is useless.

If we can display a plain ASP.NET page it is enough as a starting point to solving the problem. The .NET "wrapper" which allows instantiating FCKEditor(s) on a ASP.NET page has a property called "ImageBrowserURL". This property holds the URL of the page that can embed the required functionality.

So far so good, but we also need to pass the URL of the selected image back to the dialog and finaly to insert it in the HTML script. Fortunately this can be done by a call to the SetUrl() function located in fckeditor\editor\dialog\fck_image\fck_image.js.

The following code snippet is all that is needed:

function PassSelectedItem() {
 var url = document.getElementById('TextBoxImageUrl').value;
window.opener.SetUrl(url);
window.close();
return false;
}

It is embedded in the ASP.NET page and is executed OnClientClick of a button, which submits the selected image URL back to the dialog.
TextBoxImageUrl is the name of the TextBox control holding the selected image URL.

23.6.09

Oh, those Indians!

... or how a reputation of a IT pro is built.

For a reason I had to digg into some details on using Eval() and Bind() in a web page. Almost immediately I came to the following post: http://weblogs.asp.net/leftslipper/archive/2007/06/29/how-asp-net-databinding-deals-with-eval-and-bind-statements.aspx
Eilon Lipton explains briefly but very convincingly the diffrence between Eval() and Bind(). I needed some more details so I continued searching the web.
To my surprise I came to this two answers in dotnetspider's forum:

(click on the picture to enlarge...).

20.10.08

Ordered execution of Unit Tests in VS2008

NB: All uploaded pictures have to be enlarged in order to be viewed normaly.

Unit tests in VSTS are unordered by default. When dealing with state that must be shared among tests order becomes important. Say, we have a database and methods that add, select, uppdate then delete a record. Obviously the order is important!

Interesting enough there's no way to change the execution order of unit tests already created. Also, there is no relation between the order in which tests were created, the order in which they are added to test lists, and the order .

If you take a look at the *.vsmdi (see the picture) file you'll see the tests listed there. When I first open this file I said to myself—bingo! this was what I was looking for. Strange, however, there was no way to arrange the tests with a GUI tool, so my hope was that re-arranging the tests in this file manualy may solve my problem. Alas, I was wrong.

After spinning my mouse wheel for a while I discovered that there are "Ordered tests" that may be added to Test Project.


I added an Ordered Test to my test project and the following form appeared:


This time I was not wrong—the ordered tests allowed me to manage execution order of the unit test.
With (1) I was able to select any test list I have prepared. The unit tests appeared in the left pane (2) and I was able to select some (3) or all of them. Selected tests were added to the right pane. If the order was not correct I could re-arrange the tests with (4).

I was wondering what was the meaning of "Continue after failure" check box and although it was almost obvious I decided to run the tests with this box checked.

To my surpise there was only one (!) test in the Test Results pane—the ordered test itself. This is why this optioin had to be set as part of the ordered test itself. So it seems as if ordered tests are sort of "batch tests" or "integrated tests" which behave and run as a single unit test.

You can edit such a test but it is not a "list" in the sense of test lists you can define in Test List Editor. If you take a look at the picture below it is obvious that an ordered test is treated as single unit test, not as a list of independent unit tests.


And of course, the test results show only the execution of one and only test—the ordered test itself. So, in case of failure, how to guess which unit test participating in the ordered list has failed?

And here come the test results which are obviously much more important for ordered tests than usual, unordered, ones. At least because this is how you can tell which unit tests pass and which don't. For now I saw no other way, but maybe this is not necessaryy.

My guess is this atomic behaviour of ordered tests relates to some threading issues and transaction logic since this is how state between tests is preserved. This is however to be found out.

19.3.08

Rename SQL 2005 Server Instance


Here's a direct quotation from Google Groups
1. drop current instname (sp_dropserver)
2. add new instance name (sp_addserver 'new name','local')
3. stop sqlserver
4. modify hklm\software\microsoft\microsoft sql server\
5. modify hklm\system\mssql$
6. use "sc create" to add new mssql$
7. start up with new inst_name - voila!
... and after that...
oops. #5 should be "modify
hklm\system\currentcontrolset\services\mssql$inst"

WARNING: Not tested!

29.2.08

Shell Menu to Register and Unregister a COM Server


This entry is part of the shell related entires collection I maintain. Here is the Windows shell goody - it Registers/Unregisters a .dll. Needles to say it may be used for ComInterop assemblies too.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\dllfile\shell]
[HKEY_CLASSES_ROOT\dllfile\shell\Register]
[HKEY_CLASSES_ROOT\dllfile\shell\Register\command]
@="regsvr32 \"%L\""

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\dllfile\shell\Unregister]
[HKEY_CLASSES_ROOT\dllfile\shell\Unregister\command]
@="regsvr32 /u \"%L\""

These two snippets were taken from an article on creating shell context menus in codeproject.com.

It is the second in the sequence of shell articles. Here's the first one.

5.11.07

Clearing Visual Studio Solution folder(s)


This is a simple context menu item in Windows Explorer's context menu that cleans a solution folder from all bin, obj and .svn folders. Optionally VSS files may be added for clean-up.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\CleanSolution]
@="Clean Visual Studio Solution"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Folder\shell\CleanSolution\command]
@="cmd.exe /c \"TITLE Removing bin, obj and .svn folders in %1 && FOR /r \"%1\" %%f IN (bin, obj, .svn) DO RD /s /q \"%%f\" \""

You can download the registry file from here.

Inspired by Jon Galloway's blog.

24.9.07

Configuring vsftpd


NB: incomplete, some more evaluations are necessary!

Standalone Server

Here are the results of a lengthy and somewhat painful experience configuring vsftpd. First of all keep the original vsftpd.conf located in /etc. To do this set vsftpd to launch as a stand-alone server not a daemon - i.e. not running from an inetd. Do this by setting

listen=YES


This allows for passing different set of options to configure the server. By issuing the command


vsftpd /home/me/vsftpd.conf


where /home/me/ vsftpd.conf is another configuration file for the vsftpd server. Notice the full path to the configuration file. This allows for different configurations to test.

If there is an already running server and you want to keep it running while experimenting with some values set the following directive:

listen_port=2121


This makes the server listen at port 2121 which is not the standard ftp port (21). Thus the experimental server does not conflict with the production one.


Basic Operations

Generally speaking nothing more than a file system offers – copying, moving, renaming, deleting of files – these are the basic operations a FTP server should provide.
To allow for changing files and directories set

write_enable=YES


Setting write_enable to NO effectively denies all writes to the remote directory – you are banned from uploading files, deleting and renaming existing files, all the same with directories.


anon_upload_enable=YES


Set this directive to YES to allow for file upload. If set to NO all the basic operations will work – renaming and deleting files, moving files between directories, creating, deleting, renaming directories will still work. The only effect is that the user won’t be able to upload files.


anon_mkdir_write_enable=YES


If set to NO server’s user may not create directories – all other actions are permitted.


anon_other_write_enable=YES


If set to NO this directive stops user from renaming and deleting directories. It complements anon_mkdir_write_enable so that both control how directories are manipulated thru FTP clients.

In this case files may be only uploaded – no delete, move, rename are allowed. Overwrite, incl. repeated upload, are not permitted.

Security

(to be completed)

Logging

When something goes wrong logging helps in determining what happens with the server – starting/stopping the server, establishing/dropping a connection, transferring/manipulation remote directories and files etc.
There are a couple of directives controlling the logging process:

syslog_enable=NO


If set to NO logging goes to /var/log/vsftpd.log and /var/log/xferlog . Otherwise syslogd server is responsible for logging (not tested!).


xferlog_enable=YES


Effectively enables logging. /var/log/vsftpd.log logs everything (?) while /var/log/xferlog logs only file transfers – upload and download.


dual_log_enable=YES


When enabled log writes to both files - /var/log/vsftpd.log logs and /var/log/xferlog.


dual_log_enable=NO


If set to NO no output goes to /var/log/xferlog, otherwise transfers are logged in both log files.


log_ftp_protocol=YES


When set to YES all FTP commands and responses are logged. This directive is useful for debugging. Otherwise only client requests are logged.