28/12/2019	v.1.2.19	ADD		Added check to make sure the user has administrative privileges to change/save settings.
								This prevents writing on the wrong registry hive, and makes it readable for all users.
								Remark. This change actually happened when the new setup was created in July 2025.
								The old date has been kept for consistency with the last update of the whole suite.

15/07/2009	v.1.2.18	BUGFIX:	Retrieveing the gPacketTimeout from the system registry were wrong cause the default value were passed as
								int instead of char. Fixed.

15/06/2009	v.1.2.17	BUGFIX:	Still the gComEvt might disappear or be corrupted while passing data from the windows message (myMainWndProc) 
								process	to the function DecodeData. Doubt is the re-creation of the variable by re-entering into the threadProc
								which creates a new memory area for this variable.
						Fix:	Moved the creation of the gComEvt just at startup, in the Init function, and allowing to access it as a
								global variable. The variable is then deleted only by the library's detachment by calling the quitinstance
								function, in which all the global variables are released and deleted.
								Furthermore a check for the existance of the variable (non zero pointer) was added everywhere were used.
								In addition, the DecodeData function now does not receive the pointer to gComEvt, instead is retrieved into
								the function itself.

						Remark.	After several tests, this seemed to be the ultimate solution for the problems due to access violation.

						Change:	In CloseCOM function the call to ClearCOM has been changed to a call to PurgeComm, to avoid the need of
								the gComEvt->hCom variable which at that stage might be invalid.


12/03/2009	v.1.2.16	BUGFIX:	Creation of new gDS was missed if inserted into the threadProc by calling the PumpMessage in a multithreading
								condition, leading to a random exception of access violation 0xC00000005 error.
						Fix:	The creation of the new DStore object set to gDS has been moved just after creation of the gComEvt object
								from the heap. In addition a check has been added before any access to the global variable gDS.


20/02/2009	v.1.2.15	Release:New DLL based version released.


All information below are related to changelog of the OCX version that the DLL version inherited
------------------------------------------------------------------------------------------------
08/01/2009	v.1.1.15	Bugfix:	Some operations might close the working thread while decoding data, thus having the CME (gComEvt) global variable
								set to null. This led to an access violation.
						Fixed:	A test for the validity of the CME (gComEvt) before attempting to use it in DecodData and elsewhere it is used.

12/12/2008	v.1.1.14	Change:	Major internal change. Removed the third thread that were started when a reply were required. Moved all the
					operations that involves the handling of data in the main thread (in which the OCX runs, as the main application
					do).  Now the response to the WaitCommEvent in threadProc does call the COMmsg function which in turn post
					a message in the subclassed window queue, and no read operation is taken in place there.
					This allows to concentrate all the operations that involves data handling into the main thread of the
					application, improving the efficience (no critical sections are required anymore) and avoiding the potential
					problem of errors allocating memory, the intra-thread passage of invalid data pointers, and the need to start
					a third thread to send back replies to the network.

					Since waiting conditions are in place when a packet is sent over the network, to check for echo feedback (not echo
					packets), or to wait for a reply by a remote peer; a message pump function has been adopted: PumpWait, which
					takes a timeout (in milliseconds) and flags to compare the device status condition to exits from the waiting loop.
					This also substituted the Sleep calls used to halt the process to wait for fixed delays to adhere the protocol
					or to allow the remote device to perform the required tasks, such as after a reboot command.

					This change has been taken trying to correct a suspected bug in this OCX component, since the application 
					DomoServer crashes in some conditions and in some operating systems. In addition some rare cases of crash has
					been reported also in ide.exe clearly connected to the serial communication.

		v.1.1.12 - 13	Interim versions for testing purposes, not distributed.
		


01/11/2008	v.1.1.11	Bugfix:	Added the DStore::LastAddOK function to be sure that the DStore::AddTest has succeeded, and the related
								error handling everywhere the AddTest is used.
						Bugfix:	Added a check if the DStore::GetTest returns a valid pointer, to skip in case the function does
								not find the given key and returns a null pointer. 
								Missing of this test led to occasional access violation fault.

28/10/2008	v.1.1.10	Bugfix:	Thread which handles the parsed packets to bubble up the event DataReady, by the function
								ProcessPacket which launch the theread netevtProc missed to close the related handle causing
								to grow the handle consumption reducing the available resources of the operating system.
								Fixed:	The _endthreadex and CloseHanlde has been added at the end of the netevtProc function to
										fix this bug.
						Bugfix:	The cut function of the DStore class missed to actually cut the data reducing its m_len member
								(the size) but not the related m_data member.
								Fix: The m_data member now is updated in size accordingly by the m_len member.
								This bug might led to invalid pointer causing the crash of the application which uses the OCX component.

10/07/2007	v.1.1.9		Add:	Added a delay before sending the reprogram command to avoid the "double packet lock protection bug"

30/03/2007	v.1.1.8		Add:	Added the property NoErrMsgBox and the new event NetError to avoid that OCX will popup message boxes 
								related to network errors. When this property is set to TRUE the OCX instead to popup a message box
								will fire the event. Notice that messageboxes still will popup on errors not related to the SFBP
								network tasks.

24/11/2006	v.1.1.7		Minor bugfixes		

02/05/2006	v.1.1.6		Add:	Added the new property ResponseMsg to let specify which type of message is
								expected in response to each data packet sent to a remote peer in a stream
								or connected mode.
								This comes with a change in the fwrwprg variable which now hold the actual
								CTRLTYPE message expected, thus sending program also is made by setting this
								variable to CTRLTYPE_PRGSTATE (this is done anyway, ignoring the setting made
								to the ResponseMsg property.
								The ResponseMsg is resetted after the send is made.

						BUGFIX:	The threadProc function were set the hHeap variable to NULL when exiting and
								freeing its own private memory allocated from private heap. This was wrong
								because the heap still is live and an other thread may access to some memory
								allocated to it, which is the case of the netevtProc function.
								Infact, if a message were going to be processed by netevtProc while the 
								CloceCOM method were invoked, this bug led to an access violation fault.

						Change:	Creation of private heap now is made by leaving the third member (maxsize)
								to zero, allowing the heap to grow if required.

						Change:	The Query, GetFirmwareInfo, GetRemoteError now returns the data even if 
								target address is zero (broadcast). Before this change these functions
								do return data only if target address were any non-broadcast address.

						Change/Add: Added a new type of packet returned: CTRLTYPE_DATAEVEN which is
								returned in place of CTRLTYPE_DATA when an even packet is received from
								a stream of data.

02/04/2006	v.1.1.5		Change:	Descriptions of some errors has been improved.

29/03/2006	v.1.1.4		Change:	When sending a program (and the internal variable msendprogr is set to true)
								and the target version is below of 1.x (not send STREAM) a wait of 250ms is 
								added on each packet successfully sent.

26/03/2006	v.1.1.3		Added:	Added the method TestStream to send a stream of characters over the network.
						Updated the enumeration of CTRLTYPEs.

						Add/Change:	Added the function to send data packets with the NEXT bit set when
								packet is odd (beginning count by zero), this is done by adding the sending
								mode TYPE_STREAM. This is done accordingly with the version 1.x or above of
								the target firmware. On older devices the process is unchanged.

17/03/2006	v.1.1.2		BUGFIX: Changed the enumerated value for CTRLTYPE_USER (it was 8 instead of 43),
								and the CTRLTYPE_INSTATUS has been removed in place of CTRLTYPE_GETOUT.
								
						Add:	Added capability to deal with programming devices to flash with the related
								protocol (a CTRLTYPE_PRGSTATE packet sent back per each data packet sent).
								This behaviour happens only if the remote peer respond to query of firmwareinfo
								with version 1.0 or above. In the other cases the behaviour is as the preceeeding
								version of the driver (the ocx).
								This task is done automatically by the program and programDirect methods.

						Add:	Added the LastProgramError enumerated code to know the last error in sending
								the program to a remote peer.

						BUGFIX:	The Map event and the FirmwareInfo event both returned the version members 
								swapped	(minor and major was exchanged).

29/03/2005	v.1.1.1		Change:	Changed the default value for Adapter ID to SIMPLE instead of FAST,
								added the Protocol register key to hold protocol preference, default
								has been left to PROTO_SFBP_2

28/02/2005	v.1.1.0		BUGFIX:	Added a message handler to honor the aparthment threading model which could lead to
								random errors when firing DataReady and Error events.
						Fixed:	By adding a message loop subclassing the host window of the OCX. The subclass is
								started when the OpenCOM method is called. For this purpose such method has been
								changed adding a member parameter hWnd which should be the same of the client window.

15/02/2004	v.1.0.3		Removed some dummy properties
						BUGFIX:	ACK was sent as SFBP1 even set to SFBP2, fixed.

05/12/2004	v.1.0.2		Added:	Protocol property to the DNsccom interface, this led to changes on the _senddata function
								and the parsePacket function to deal with either SFBP version 1 and 2, where checksum is
								handled as a CRC (cyclic redundant checksum) whereas the simple checksum was used in SFBP v.1.

								Setting the protocol property let choose for SFBP v.1 or v.2, default has been set to the 
								latest version.

13/07/2004	v.1.0.1		First release