Visual Basic 6.0 Error: ‘Compile Error: Procedure declaration does not match description of event or procedure having the same name’

System Requirements:

  • Visual Basic 6.0

The Problem:

After copying a control placed on a form in the VB 6.0 IDE you receive the following error message when you attempt to run the program.

Compile error:

Procedure declaration does not match description of event of procedure having the same name

Compile Error Message

The program will not compile correctly even after the VB control that you copied has been deleted from the form.

More Info

This seems to be a bug in the VB 6.0 IDE. Remember this?

Create Control Array Message

It asked you if you wanted to place the control into an array so that multiple controls named ‘Command1’ in this case could be referenced from a common name i.e. Command1(0), Command1(1), Command1(2) etc.

Very occasionally the VB IDE gets this wrong, attempting to reference a control variable as an array variable. This in turn leads to non-compliable code and no clear way to get out of the problem.

The Fix

The fix is to prevent the VB IDE from trying to treat the original variable as an array by removing its index parameter.

  1. Delete or rename the duplicate named control
  2. Note the name of the control in the error message
  3. Save your project and exit VB
  4. Open the location of your .vpb (Visual Basic Project) file
  5. Locate the .frm file (form) that your control appears in amongst the list of files
  6. Open notepad and drag and drop the .frm file into its window so that you can see the underlying code-behind the form
  7. Search the file for the name of the control named in the error message
  8. Beneath it you should find a parameter list associated with the control. Locate and delete the line “Index” line as highlighted below
  9. Save and exit notepad and restart the IDE

Or, if the control exposes it, clear the value of ‘index’ on the properties explorer in the IDE.

The Fix in Notepad

Printing to an O’Neil Route Printer RP2000-8000 Line Mode (COM) Printer using embedded Visual Basic (eVB) on Windows CE and Windows Mobile

System Requirements:

  • Microsoft embedded Visual Basic
  • Windows CE 2.11, 3.0, 4.0, 4.1, 4.2, 5.0
  • Pocket PC 2000, 2002
  • Windows Mobile 2003, 2003SE, 5.0

The Problem:

Although this article specifically addresses a problem that I had between a Symbol PDT8046 and the O’Neil Route Printer RP2000-8000, the issue and resolution should be applicable to any serial (COM) port based line printer.

If you have a raw ascii line printer, you can check to see if the printer works by echoing directly from the stdout into the COM port. Under DOS or the Windows command shell on the PC or Pocket DOS on Windows CE/Windows Mobile issue the following commands

mode com1: 9600,n,8,1,r
mode lpt1:=com1:echo I am a fish > lpt1

This will send I am a fish and a line feed to COM1 at 9600bps with no parity. Note that Pocket DOS doesn’t support the “,r” parameter.

So now that you have ascertained that the printer actually works, when you use the Microsoft Communications Control (Microsoft Comm Control) for embedded Visual Basic (eVB) to send the same data, why is it that nothing happens what so ever.

More Info

Let us look at the VB

‘ Set to COM1, 9600bps, no Parity.
‘ Enable DTR Flow Control, disable RTS Flow Control, disable handshaking
msComm.CommPort = 1
msComm.Settings = “9600,n,8,1,r”
msComm.DTREnable = truemsComm.RTSEnable = false
msComm.Handshaking = 0

‘ Attempt to get control of the COM port if it isn’t available
On Error Resume Next
if (msComm.PortOpen) then
msComm.PortOpen = false
end if
On Error Goto 0

‘ Open the port, Send the message, shutdown the port
msComm.PortOpen = true
msComm.Output = “I am a fish” & Chr(13) & Chr(10)
msComm.PortOpen = false

This is a logical flow of execution and basically what on the surface the DOS version is doing. Yet the message I am a fish will never arrive at the printer. In fact, the printer will not even acknowledge the presence of the message.

The Fix

This code is in fact completely logical, and is right (for the O’Neil RP2000-8000 anyway). However after some frustration and experimentation I discovered that there are two important pieces of the puzzle missing, one of them strongly recommended and the other very much mandatory.

Issue 1: Sleeping Printer

The O’Neil printer will go into standby mode after a couple of minutes of idle time so as to conserve power. If the printer is in sleep mode and you send data to it, it probably will not be awake to receive information and send it to the print head fast enough; best case nothing happens and worst case less than half of your message gets printed.

The O’Neil hardware manual has a very short section on this. In order to wake the printer up (or ensure that it is awake) you need to send a string of ASCII NULL characters (0x00) at the printer. For ONeil line mode printers operating at 9600bps you need to send this string 6+ times. For 38,400bps printers you should send this 24+ times. In our VB world that means:

msComm.Output = Chr(0) & Chr(0) & Chr(0) & Chr(0) & Chr(0) & Chr(0) & Chr(0)

7 times is a charm, however the manual also states that you should wait 150ms before sending data to the printer. See the next section on implementing Sleep().

If you repeat your test now, your printer should at least wake up even if nothing else happens

Issue 2: Speed = Distance / Time

I could wax lyrical on this, but Ill keep it brief.

There are a couple of buffers at play in the form of the OS and the printer, the embedded operating system and the eVB runtime processor. All of which cause delays. It follows something similar to this

  1. User Sends Print Request
  2. eVB Runtime Parses the command and sends it to the native code of the machine
  3. Operating System queues it in RAM as it gets processed through and send on its merry way
  4. Operating System queues it in the COM port transmit (TX) buffer
  5. Printer receives the message and queues it in the print buffer (512 bytes I *think* on the RP2000-8000)
  6. Printer processes it forward to the print head and the line at the front of the queue is printed

eVB does not care about steps 3 – 6, neither is it aware of them. As far as eVB is concerned, it has finished with the msComm.Output() command as soon as it has received an OK from the operating system that the requests has been through the processor and the data is in a queue.

Referring back to our original code

‘ Set to COM1, 9600bps, no Parity.
‘ Enable DTR Flow Control, disable RTS Flow Control, disable handshaking
msComm.CommPort = 1
msComm.Settings = “9600,n,8,1,r”
msComm.DTREnable = truemsComm.RTSEnable = false
msComm.Handshaking = 0

‘ Attempt to get control of the COM port if it isn’t available
On Error Resume Next
if (msComm.PortOpen) then
msComm.PortOpen = false
end if
On Error Goto 0

‘ Open the port, Send the message, shutdown the port
msComm.PortOpen = true
msComm.Output = “I am a fish” & Chr(13) & Chr(10)      <—— My work as VB is now over
msComm.PortOpen = false                                    <—— Shutdown the COM port

What is happening? eVB thinks that everything has been delivered and shuts down the COM port before the data has left the sending device and is safely received into the printers hardware buffer.

What is the solution? Well, you can be as eloquent or in-eloquent as you like. You can do a byte by byte check of data into the VB transmit buffer, ensuring that this has gone before you progress through the output stream. Alternatively if you are feeling lazy you could use the threading model and implement a fixed length sleep action. If however you are feeling somewhere between the two extremes you can try and weight the sleep timer based upon message length. Something along the lines of

delay (ms) = Absolute(((Length(Message) / ((Printer Bit Rate * 0.50) / 8 )) * 1000))

A weighting of 0.66 is assumed so that the link speed and buffer writing can be running at only 1/2 of line speed. Division by 8 is used to convert from Bits Per Second to Bytes Per Second. Multiplication by 1000 converts the value to milliseconds.

or for the RP2000-8000 with message “I am a fish <cr><lf>” [13 characters]

delay (ms) = Abs(13 / ((9600 * 0.66) / 8) * 1000)

or 21 ms

Onto this you may want to add a standard value that reflects the time the message takes to leave the operating system onto the wire. 50 – 100ms should do.

In order to use the thread sleep function in eVB you have to import the export from the C++ corelib as follows

Declare Sub Sleep Lib “Coredll.dll” (ByVal dwMilliseconds As Integer)

Dim strMessage
strMessage = “I am a fish” & Chr(13) & Chr(10)

‘ Set to COM1, 9600bps, no Parity.
‘ Enable DTR Flow Control, disable RTS Flow Control, disable handshaking
msComm.CommPort = 1
msComm.Settings = “9600,n,8,1,r”
msComm.DTREnable = true

msComm.RTSEnable = false
msComm.Handshaking = 0

‘ Attempt to get control of the COM port if it isn’t available
On Error Resume Next
if (msComm.PortOpen) then
msComm.PortOpen = false
end if
On Error Goto 0

‘ Open the port, Send the message, shutdown the port
msComm.PortOpen = true
msComm.Output = strMessage
call Sleep((Abs(((Len(strMessage) / ((9600 * 0.50) / 8)) * 1000)) + 50))
msComm.PortOpen = false

Note: This code is highly summarised it will not work directly as a copy/paste, you need to modularise it and create the msComm object.

With the sleep function in place and the correct tuning you should now find that the data gets to the printer before eVB closes the COM port.

Remember that you need to implement the function of Sleep(150) after sending the wake-up NULL string to the printer.

C:Amie’s StopWatch for Windows CE and Handheld PC

System Requirements:

  • Windows CE 2.11, 2.12, 3.0, 4.0, 4.1, 4.2
  • Handheld PC Professional
  • Handheld PC 2000 (HPC2000)
  • VBCE Runtime

About:

StopWatch does more or less exactly what it says on the tin. It is a timer that you can stop… and start… and clear.

The program is designed not to hook the RTC in calculating the time, what is meant by that is that the application does not take note of, nor care about when precisely it was that you started the timer as is the case with some of the other timer applications available for CE.

Why does this matter?

Well, with a timer that hooks the RTC values, when you suspend the device and resume it after x amount of time, the application will re-value the current time against the start time and adjust the value accordingly. This program was designed to maintain counting arithmetic each side of the suspend/resume application.

Why would I want this?

Well, you might not, however if you are looking for this, I am sure that you have a good reason for it. The reason why I wrote the application in this was was because I wanted a visual indicator to time battery depletion from max charge to the point at which CE’s power management forcefully suspends the hardware. Once suspended, when you connect it back to AC ad resume the system, the value on the screen will be the value that the system powered off at, rather than a recalculated value between then and now.

Do however note that the time will continue ticking on resume.

C:Amie's StopWatch

Current Version:

1.0.3

License:

Freeware

Price:

Free

Source Availability:

Closed

StopWatch makes no registry modifications and writes no data into the file system of your Handheld PC (the VBCE RTL does make additions to the registry), it is low footprint, transportable and can be run from main RAM or a CF Storage Card.

Changelog:

The table below contains a list of changes made to StopWatch.

Version Number Changes

1.0.3

  • C:Amie branding added
  • Clear button logic changed so that it no longer stops the timer if it is already running
  • Hyperlink support for CE .net 4.x to www.c-amie.co.uk added
  • Automated interface version numbering added

1.0.2

  • Canvas size reduced
  • Timer Font Size Expanded
  • Hyperlink for HPC2000 systems to www.c-amie.co.uk added

1.0.1

  • Added toggelable Start/Stop button
  • Clear Button Added

1.0.0

  • Initial Release for Thaddeus

Installation:

The following steps outline the installation procedure for the StopWatch.

Visual Basic CE Edition

  1. Download either the VB application from below
  2. Download the VBCE runtime from H/PC:Update (if required)
  3. Upload the VBCE runtime installer to the device and install by double clicking the cab file and following the instructions on the screen
  4. Soft Reset the Handheld PC
  5. Upload the application file (.vb file) to the Handheld PC
  6. Double-tap the .vb to launch the program

.net Compact Framework Edition

  1. Download the .net CF application from below
  2. Download the .net Compact Framework runtime combination from H/PC:Update (if required)
  3. Install the .net Compact Framework using ActiveSync to your Handheld PC
  4. Soft Reset the Handheld PC
  5. Upload the application file ( .exe file) to the Handheld PC
  6. Double-tap the .exe to launch the program

Download:

This application is closed source, its use is entirely down to you the end use, no warranty is implied or offered.

Requirements

StopWatch for CE 2.10+: You will need to have the VBCE Runtime libraries installed (CE2.11+) on your device. The Minimal version of the VBCE runtime from H/PC:Update (link below) will enable operation under CE .net. HPC Pro and HPC2000 users already have the RTL in ROM.

StopWatch.net for CE .net 4.20+: You will need the .net Compact Framework 2.0 SP2 installed. The .net Compact Framework can also be downloaded from H/PC:Update.

Download: C:Amie’s StopWatch 1.0.3 (VB Application only) (5 KB)

Download: C:Amie’s StopWatch 1.0.3 alpha (.net Compact Framework 2.0 Application) (8 KB)

View: H/PC:Update on HPC:Factor