Navigation

In a medical device software I'm currently developing, I need a popup window animating like the windows poping up from the task bar. After some experiment, I got the following that works satisfactorily.

    Private Sub Form1_MouseClick(ByVal sender As System.Object, ByVal e As System.Windows.Forms.MouseEventArgs) Handles MyBase.MouseClick
        Dim screen = PointToScreen(e.Location)
        Dim dlg As Dialog1 = New Dialog1
        dlg.Opacity = 0.4
        Dim size As Size = dlg.Size
        Dim top As Integer
        Dim left As Integer
        dlg.Enabled = False
        For s As Single = 0.1 To 1.0 Step 0.1
            top = screen.y - size.Height * s
            left = screen.x + 10 * s
            If top < 0 Then
                top = 0
            End If
            'If left > Parent().Right - 10 Then
            '    left = Parent().Right - 10
            'End If
            dlg.Bounds = New Rectangle(left, top, s * size.Width, 20)
            If dlg.Enabled = False Then
                dlg.Enabled = True
                dlg.Show(Me)
            Else
                dlg.Refresh()
            End If
            System.Threading.Thread.Sleep(16)
        Next s
        top = screen.y - size.Height
        left = screen.x + 10
        If top < 0 Then
            top = 0
        End If
        'If left > Parent().Right - 10 Then
        '    left = Parent().Right - 10
        'End If
        dlg.Bounds = New Rectangle(left, top, size.Width, size.Height)
        dlg.Opacity = 1.0
        dlg.Refresh()
    End Sub

class CaptureCine
{
public:
    CaptureCine() : ___ {}

    void StartCapture(LPTSTR lpFilename) {
        HRESULT hr = AVIFileOpen(&pAVIFile, lpFilename, OF_WRITE|OF_CREATE, NULL);

	BITMAPINFOHEADER bi;
	bi.biSize = sizeof(BITMAPINFOHEADER);
	AVISTREAMINFO si;
	memset((void*)&si, 0, sizeof(AVISTREAMINFO));
	si.fccType = streamtypeVIDEO;
	si.dwRate = 30000;
	si.dwScale = 1001;
	si.dwQuality = -1;
	SetRect(&si.rcFrame, 0, 0, (int)640, (int)480);
	hr = AVIFileCreateStream(pAVIFile, &pAVIStream, &si);
	hr = AVIStreamSetFormat(pAVIStream, 0, (LPVOID)&MyBitmapInfo.bmiHeader, sizeof(BITMAPINFOHEADER));
	lStreamSize = 0L;
    }

    void CloseAVI() {
	if (pAVIStream)
		AVIStreamRelease(pAVIStream);
	if (pAVIFile)
		AVIFileRelease(pAVIFile);
    }

    void AddFrame()
    {

    }

private:
    // variables for video capture
    PAVIFILE pAVIFile;
    PAVISTREAM pAVIStream;
    LONG lStreamSize;
}

After an update of source code from the repository, I was disguise to see that my program developed all kind of program: crashing, producing incorrect result, etc, etc.

Evidently, some people changed the semantics but not the syntaxes some class's interface. All my program still compile in the automated build but since I didn't write the unit tests for some of significant functional components of the application, the logic that was messed up by the semantic change of the other classes didn't reveal in the automated build.

Have I had written unit tests for the functional components for my application, I would not be the person fixing my code to fit the other people's change.

I was writing a function to perform linear interpolation of a list of spectrum:

List LinearInterpolation(List source)

I was tempted to return a null if the source is empty. Then I realized returning an empty list is better. Not only the does not have to check for null return, it also is more elegently in agreement with the input. user

Well, I added a parameter to a method of a class in a C++ project. I hit the build key, expecting several errors to pop up. I was mistified that the project built without a single error.

Shorting of rebooting the computer, I did everything people would do to detect a no existing error. But the project kept building without error. Will I did suspected for a second or two that maybe a parameter with a default value exists so the build was not broken by the addition of the new parameter. But I quickly brushed the idea behind, considering that the new paramter added was of type bool before a parameter of type std::ostream&.

Not until a long time of frustration later, did I realize there's no bug in the compiler. It is indeed a parameter with a default value that allows the method with an additional paramter of type bool to be compatible to all the existing calls to the method because, std::stream& can be casted into bool implicitly.

I have a CVS repository hosted in a Windows 2000 Professional system. I installed CVSNT in the system. To use SSH for cvs, I also installed cygwin. Things has appeared to be working smoothly for quite some time. Then yesterday, I imported some source file into the repository but changed my mind. I set out to delete the files in the server using in the Windows Explore. But I kept getting the message that the files are in use. I stopped the CVSNT service, but the error persisted. It took a lot of digging, before I realize that a copy of cvs.exe inside cygwin is been used when a cvs request comes in via SSH. Using netstat, I confirmed that there's no server listening at the cvs port. cvs via SSH works anyway.

I came to the conclusion that by using ssh, the cvs command was tunnelled and executed in the server. The results are then transported back to the client via the ssh connection. And to delete any files created in the process, it has to be done withing cygwin.

Entry in the "Windows/System32/Drivers/etc/hosts" file effects things like MySql database access. e.g. an entry
192.168.0.101 www.myweb.com
will cause any user 'joe'@'102.168.0.101' be denied access to the database as the client is considered to be accessing from 'www.myweb.com'.

My current coding time versus unit testing time ratio is 1:1. If most bugs are uncovered through unit testing, it should be a productivity improvement.

The major advantages of practicing unit testing as one is to uncover and fix bug early. I also noticed that unit testing helps flush out exceptional conditions that were missed at coding.

Slowly, I'm getting into the habit of writting unit tests for my code as I write them. I'll see how much more efficient this will turn out. I hope I'll not be speding too much time writing and debugging the unit tests themselves.

Over the years practicing software engineering, I become firmly beliver that a library or API publisher shall publish a comprehensive unit tests along the library.

I have a .NET Form based class and I'm writing unit tests in NUnit. My plan is to create the form in a thread and observe it to update in a "TestFixture" class:

 1    [TestFixture]
 2    public class MyFormTestFixture
 3    {
 4        private bool FormOpen
 5        {
 6            get { return myFormHandle != (IntPtr)0; }
 7        }

          // store the handle of the MyForm object so this
          // can post message to the form
 8        IntPtr myFormHandle = (IntPtr)0;
 9        Mutex mutex = new Mutex(false);
10    }

The first test is to show the form. It can be easily accomplished by creating a thread in which an object of MyForm is created and passed to an Applicaiton.Run() function, which will display the form window and start the message pump for the window:

01        [Test]
02        public void ShowForm()
03        {
04            Thread thread = new Thread(delegate()
05            {
                  // TODO enclose from here and "myForm.Handle" in a critical section
06                MyForm myForm = new MyForm();
07                myForm.FormClosing += WatchFormClosing;

08                myForm.Text = "Spectrum";
09                myForm.YAxisTitle = "Intensity";
10                myForm.GraphTitle = string.Format("Form Title");
11                myForm.XAxisTitle = "Wavelength (nm)";

                  // the main thread will not be able to
                  // call get_Handle in debug mode
12                myFormHandle = myForm.Handle; // store the handle for the main thread to use

13                try
14                {
15                    Application.Run(myForm);
16                } catch (ThreadAbortException e) {
17                    myForm.Close();
18                }
19            }
20            );

              // to allow ole call (context menu)
21            thread.SetApartmentState(System.Threading.ApartmentState.STA);
22            thread.Start();
              // wait for the thread to start running and the form opened
23            while (!FormOpen)
24            {
25                System.Threading.Thread.Sleep(10);
26            }

              // display the form for ten seconds, or until
              // it is closed my the user, which ever is sooner
27            UInt16 n = 100;
28            while (FormOpen && --n > 0)
29            {
30                System.Threading.Thread.Sleep(100);
31            }

32            if (FormOpen)
33            {
34                mutex.WaitOne();
                  // TODO: replace the hard coded message id with WM_CLOSE
                  // or is there a correct way to terminate an UI thread?
35                PostMessage(myFormHandle, 0x0010, 0, 0);
36                thread.Join();
37                mutex.Close();
38            }
39        }

Notice that the primary machanism of communication between the UI thread and the parent thread is via the Windows Handle of the MyForm object created in the UI thread (e.g. line 35 that instruct the form to be closed). Instinctively, one would like to store a reference to the MyForm object. However, .NET throws an exception if the parent thread would try to access the Handle property of the control that is created in the other thread, at least in the debug mode. For now, we'd give the .NET architect team the beneafit of doubt and assume they have a good reason for this.