Read_Me.txt File

Files included :

for ocx
	outgoing5.bas						source file
	outgoing.rc							resource file to embeed the outgoing.tlb
	outgoing.tlb						typelib file (produced by compiling outgoing.idl   with midl.exe)
	outgoing.idl						idl file , description of the ocx classe, interfaces...
	outgoing.ocx						the "dll"  activex component file

for executable test
	outgoing_test5.bas				source file
	ComCtrl5.bi							include source file for ocx interfaces description
	Ax_lite5.bi							include source file, minimal framework for COM
	outgoing_test5.rc					resource file to embeed Outgoing_test5.Exe.Manifest and infos properties
	Outgoing_test5.Exe.Manifest	manifest file for outgoing_test5.exe, embeeding Xp control behaviour and
											registration sxs for outgoing.ocx ( does not needed to be registered)
	Outgoing_test5.Exe				executable file

for help register/unregister the ocx
	Reg_outgoing.bat					batch to register the ocx 		(has to be on same folder as ocx to work)
	UnReg_outgoing.bat				batch to unregister the ocx		same remark as above

information : this is a sample ocx visual component for win32

The ocx includes 2 OleAutomation interfaces : 1 interface + 1 event interface (vtable only)
both inherit from IUnknown (no dispatch usage , so does not work with scripts , and for VB6 not tested)

the ocx can be registered as a normal one,
but the test executable can work with it registered or not ( side by side registration via manifest)

if ocx registered:  the exe does not need to know where is the ocx file ( the registry give all the information)
				in that case the ocx can be registered from anywhere...
				that means not a obligation to have the ocx in the same folder as the exe, it is the normal way.

if not registered: the exe needs to be on the same folder as the ocx,
				the Outgoing_test5.Exe.Manifest is not needed because already embeeded in the rc file

The activation of the component is automatic, but it does not follow all the rules to be activated via Atl container.
All the interfaces for the full Atl activation are not implemented.

If the object is activated via 2 separated steps : CoGetClassObject and CreateInstance ( as it is done in the test)
beetwen the 2 steps the client ( exe) indicates the server (ocx) where is the "container" window parent
via the IOleWindow interface , so the server can use that "pseudo-container" to operate normally.

If the object is activated by coCreateInstance , a specific work-arround is included in the ocx code:
it search for a specific window name/class to verify if is the right "container" and can activate automaticaly also

But manual activation is always possible via 2 methods of the interface : Initialize  and CreateControl

At the end, it is just a demonstration prototype to make ocx directly from FreeBasic.


Feel free to test, modify and use it, as template for your own needs...

If you notice some wrong point or possible improvement, do not hesitate to contact me:

directly by email : marpon@aliceadsl.fr
or via the http://www.freebasic.net/forum/   or even http://www.planetsquires.com/protect/forum/index.php

my login name is marpon for Marc Pons

