We have reached what we feel is another mile stone in the OA32 progress. ? There has been improvements and expansion of the project, as well as additional work has been invested in this release to reinforce the work already done; Namely more simple and direct tutorials.

Below is a list of some of the features:
    [*]Works with Hutch's MASM32 Package
    [*]Supported by RadASM version 2.1.0.7 or greater.
    [*]Model improvements and extensions.
    [*]Static object implementation.
    [*]New debugging features and a new debug console.
    [*]COM aggregation supported.
    [*]COM OCX demo application.
    [*]DirectX support and demo application.
    [*]Translation of Iczelion tutorials 3 - 11.
    [*]More projects.
    [*]...and much more in this new release!

    We welcome your feedback. ? If your new to this project, simply download it and check out the Demo's or the Nan_Tuts. ? The Nan_Tuts were deliberately desigend to reflect each of Iczelion's famous tutorials. ? Since most if not all of you are familiar with these tutorials, it was my hope that it would help sever as a basis to teach the Object Orientated approach to the same problem in each tutorial. ? I didnt copy the origional tutorials, so I leave it to you review Iczelions' work from his many sites. ? However, I did make a large effort to ensure my equivalent demos are well commented.

    Please provide your feed back, good or bad.

    You can get the download at the following site:ObjAsm32 Home Page

    Please let us know if the bandwidth gets chewed up. ? We will make additional provisions to offer the package in this case.

    Best Regards and have fun!
    :alright:
    :NaN:
Posted on 2005-02-09 17:53:28 by NaN
Hi Biterider + NaN,

> Please provide your feed back, good or bad

The setup program allows to choose a different folder (and drive) for OA32 than for MASM32, but after I selected C:\ObjAsm32 and D:\MASM32 I had some difficulties to get anything to work. The idea of oa32_setup.inc with path equates is good, but the source sometimes seems to ignore these definitions.
Posted on 2005-02-10 01:29:05 by japheth
Hi Japheth!
Thanks for your feedback. I'll check if I have forgotten to modify some parts of the code...

Regards,

Biterider
Posted on 2005-02-10 04:24:17 by Biterider
It's a normal problem with masm32, imho - I always keep asm/C/C++ code in D: in order to stay away from such faults. There are already two or more folders on my HDD that contain ml.exe, all registered in %PATH% . Just to save you a minute or two:


;------------[ find where MASM32 is ]--------------------------------------\
.data
;compilation1 db "C:\masm32\bin\ml /c /coff pbmp_out.imp",0
;compilation2 db "C:\masm32\bin\lib pbmp_out.obj /out:%s.lib",0
masmfolder db "C:\masm32",0
.code
mov ebx,'C'
@@:
mov masmfolder[0],bl
;mov compilation1[0],bl
;mov compilation2[0],bl
push ebx
invoke GetFileAttributes,addr masmfolder
pop ebx
inc ebx
cmp eax,-1
je @B
;--------------------------------------------------------------------------/
Posted on 2005-02-10 12:37:38 by Ultrano
I played with the OCX sample a bit (called LED server) and run into some problems:

1. The first problem was that I wanted to modify IOleObject.inc but got assembly errors, even for the unmodified version. The reason seems to be that I once converted the include files of masm32 with l2extia. With these include file versions oa32 doesn't work. In my case it was GetClipboardData. This name is a valid user32 function and a method of IOleObject.as well. l2extia creates an equate in user32.inc:

GetClipboardData equ <_imp__GetClipboardData@4>

which caused the problem. As a workaround I modified user32.inc temporarily.

2. The modified version of IOleObject.inc is



Method IOleObject.DoVerb,uses esi, dVerb:dword, pMsg:Pointer, pActiveSite:Pointer, \
dReserved:dword, hParent:Handle, pRect:Pointer
local pUnknown:ptr
local cauuid:CAUUID

DbgText "IOleObject.DoVerb"
DbgDec dVerb
SetObject esi
.if dVerb == OLEIVERB_PROPERTIES
.if [esi].pIOleClientSite != NULL
push ecx
ICall [esi].pIOleClientSite::IOleClientSite.QueryInterface, addr IID_IOleControlSite, esp
pop ecx
.if SUCCEEDED(eax)
push ecx
ICall ecx::IOleControlSite.ShowPropertyFrame
pop ecx
push eax
ICall ecx::IOleControlSite.Release
pop eax
.else
mov eax, E_NOTIMPL
.endif
.if (eax == E_NOTIMPL)
push 0
externdef c IID_ISpecifyPropertyPages:IID
ICall esi::IUnknown.QueryInterface, addr IID_ISpecifyPropertyPages, esp
pop ecx
.if (eax == S_OK)
push ecx
ICall ecx::ISpecifyPropertyPages.GetPages, addr cauuid
pop ecx
push eax
ICall ecx::ISpecifyPropertyPages.Release
pop eax
.if (eax == S_OK)
mov pUnknown,esi
.const
wszProperties dw 'P','r','o','p','e','r','t','i','e','s',0
.code
invoke OleCreatePropertyFrame, hParent, 32, 32, \
offset wszProperties, 1, addr pUnknown,\
cauuid.dElems,cauuid.pElems, 0, 0, 0
mov eax,S_OK
.endif
.else
mov eax, OLEOBJ_S_CANNOT_DOVERB_NOW
.endif
.endif
DbgComError eax
.endif
.elseif dVerb == OLEIVERB_ABOUT ;About Dialog requested (= 1)
OCall $New(DialogAbout, Init, esi, hParent)::DialogAbout.Show
xor eax, eax ;Return S_OK
.else
mov eax, E_NOTIMPL
.endif
MethodEnd


The idea of the changes is to show the property pages by myself if IOleControlSite doesn't do it (which is legal, since this function is optional). But I couldn't find out how to directly get the ISpecifyPropertyPages interface with OA32, so I had to use QueryInterface/Release, which is very ugly. (BTW, I was also unable to use the CUStr macro to define a wide string, so I defined the string the hard way).

3. comview always shows the server state as "loaded", it never is in "activated" or "uiactivated" state. So obviously the control currently doesn't call the required container function calls.

4. The dll remains loaded in memory after the object is released. I suspect this is due to some missing Release calls.
Posted on 2005-02-12 05:06:00 by japheth
> 4. The dll remains loaded in memory after the object is released.

Apparently this no longer happens with the modified version of IOleObject.inc.
Posted on 2005-02-12 08:38:27 by japheth
Hi Japheth!
I have been working on a more flexible way to install the package and I can say that I?m 90% ready. Some difficulties remain with the RC compiler when used from inside RadAsm, but I?m sure that KetilO can help us to setup all properly? The new approach is using 2 environmental variables to specify the OA32 and the MASM32 paths, since the last one can also be installed somewhere else.

Concerning the Led OCX, you are right with the name collision. I?ll change the interface method name a bit to avoid it.
I tested your changes (switching first all LoadObjects to MakeObjects in the asm file) and it worked well.
The way I planed to get an interface is using the Component.GetInterface method defined in COMPrimers.inc. This method searches in the interface collection for the proper IID and returns an interface pointer. It is the object internal equivalent for QueryInterface. Since the interfaces are stored in a collection, there are other ways to retrieve this info too.
There a 2 ways to reference an UNICODE string, the first is

invoke OleCreatePropertyFrame, hParent, 32, 32, \ 

$OfsCUStr("Properties"), 1, addr pUnknown,\
cauuid.dElems,cauuid.pElems, 0, 0, 0


or define somewhere

CUStr wszProperties, "Properties"


and then

invoke OleCreatePropertyFrame, hParent, 32, 32, \ 

offset wszProperties, 1, addr pUnknown,\
cauuid.dElems,cauuid.pElems, 0, 0, 0


I personally prefer the first.

Your point 3 is right. I have to implement it.

Finally, point 4, how do you know that the DLL remains in memory? In my tests, the DLL_PROCESS_DETACH was called and as far as I know, this was enough to guarantee that the DLL was (can be) freed from memory?

Thanks for testing! :)

Regards,

Biterider
Posted on 2005-02-12 10:39:12 by Biterider
> how do you know that the DLL remains in memory?

Usually I set switch "call CoFreeUnusedLibraries after Release" in comview and then check with a process viewer if the dll has vanished. But I cannot reproduce the error with the original version. It disappears as it should if I open and close a container window. Problems occur only if I don't open such a window (that is, I create an led object instance and then immediately close the "object" dialog). Then I get various errors, sometimes GPFs. But that is minor, since a control usually is created inside a container.
Posted on 2005-02-12 11:37:42 by japheth
Hello Biterider,


or define somewhere

Code:
CUStr wszProperties, "Properties"


This works now, it was a missing UString.inc in IOleObject.asm which caused the error.

I'm having another very interesting problem. When I enter

ml -c -coff -Cp IOleObject.asm

I get no errors, but when I want a listing and enter

ml -c -coff -Cp -Fl IOleObject.asm

masm displays some errors:

Assembling: IOleObject.asm
WinPrimer.inc(21) : error A2018: invalid use of external symbol
MacroLoop(3): iteration 1: Macro Called From
MacroLoop(9): iteration 1: Macro Called From
CreateEventStructure(20): Macro Called From
ObjectEnd(38): Macro Called From
WinPrimer.inc(21): Include File
Dialog.inc(43) : error A2018: invalid use of external symbol
MacroLoop(3): iteration 1: Macro Called From
MacroLoop(9): iteration 1: Macro Called From
CreateEventStructure(20): Macro Called From
CreateEventStructure(5): Macro Called From
ObjectEnd(38): Macro Called From
Dialog.inc(43): Include File


it may be a - strange - MASM bug, but if so you possibly ran into this error already and know a workaround?

Regards

Japheth
Posted on 2005-02-14 03:10:03 by japheth
Hi Japheth!

The support for UNICODE strings is in the Code\Macros\UStrings.inc file.
Add the following line to the first include block of the IOleObject.asm file:

% include &MacPath&UStrings.inc


and recompile it.

Regards,

Biterider
Posted on 2005-02-14 05:02:07 by Biterider
Hi Japheth
I haven't seen it before, but I have to admit that it's a long time that I didn't generate a listing. I suspect that it's an internal error of ML that's not capable to resolve an external symbol for a listing the same way it does for the compilation.
I also found some other compilation problems related to segment organization...
I'll see if I can find out what is generating the listing problem.

Regards

Biterider
Posted on 2005-02-14 08:44:29 by Biterider

I also found some other compilation problems related to segment organization...


Yes, there is one known bug, maybe it helps: (check the lastest posts of the thread)
http://217.160.247.193/index.php?topic=7797.0
Posted on 2005-04-22 02:43:30 by MazeGen