OpenEuphoria

2. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at g?ail.?om> Oct 02, 2007
• 723 views

Rad wrote:
> 
> }}}
<eucode>
 pBstr = invoke( OC6, {OneCryptA_m_EncryptString},
 			  {alloc_bstr(OW6AppId), alloc_bstr(OCString)},
 			  {VT_BSTR, VT_BSTR}, DISPATCH_METHOD )
 
 void = message_box("Input String = " & OCString & "\n" &
 			"pBstr = " & sprintf("%d", pBstr),
 			"msg", MB_ICONINFORMATION)
 
 setText(EditText19, peek_bstr(pBstr))
 </eucode>
{{{

> 
> Whatever be the value of EditText18, pBstr always comes back with fixed value
> 2147614729.
> And following error is generated at the syntax line of setText(EditText19,
> peek_bstr(pBstr))-

This is actually an error code.  Try putting:

com_err_out( 1 )

Somewhere above this call.  You should get an error message (which might
or might not be helpful).  The method might want named parameters, in 
which case you could change the call into:

pBstr = invoke( OC6, {OneCryptA_m_EncryptString, 1, 2},
        {alloc_bstr(OW6AppId), alloc_bstr(OCString)},
        {VT_BSTR, VT_BSTR}, DISPATCH_METHOD )
 

> I tried to get the return value in a sequence but got type mismatch error.
> 
> How to get a String as return value for this method?

If the method is successful, it should return it as a sequence.  invoke()
will convert the return variant to the appropriate data type automatically,
but you do have to check for errors.  Note that com_err_out() can be
redirected to a routine_id so that you can do custom error handling.

Also (you probably know this, and it's just for expediency in getting it
working, but...) calling alloc_bstr() inside the call to invoke will
leak memory, because you don't have the pointer around to call free_bstr().

Matt

4. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at ?mail.com> Oct 02, 2007
• 746 views

Rad wrote:
> 
> I used com_err_out( 1 ) and got following display:
> 
> 80020009: Exception occurred.
> Exception Source:
> Exception Description:
> 
> Hope number 80020009 gives some indication about exception as Source and
> Description
> are empty.

Unfortunately, that's just a generic message, "Hey, something went wrong!"
It's usually given when something bad happens that they didn't expect.
 
> I also tried:
> 

OCString = invoke( OC6, {OneCryptA_m_EncryptString, 1, 2},
                   {pBstrAppId, pBstrOCStr},
                   {VT_BSTR, VT_BSTR}, DISPATCH_METHOD )

> 
> but got the following error:
> 
> 8002000E: Invalid number of parameters.
> Exception Source:
> Exception Description:

Hmmm....One other way to try calling it:

OCString = invoke( OC6, {"EncryptString", "Key", "InString"},
                   {pBstrAppId, pBstrOCStr},
                   {VT_BSTR, VT_BSTR}, DISPATCH_METHOD )

This allows eucom to ask the COM object what it likes to call the
parameters.

If that doesn't work, then I'm not sure what else to try.  Is there any
sort of initialization that has to be done (license key, initialization
routine, etc)?

I suppose one other issue that I notice is that the name of the interface
ends with an 'A'.  In Win32, this usually denotes an ANSI string format.
COM objects are all supposed to use multi-byte strings (which is what 
a BSTR is).  Maybe they're really using ANSI strings?  You could try
passing a pointer to something from allocate_string() as a VT_I4.  That's
really a last ditch desperation attempt, though.

One thing I've done sometimes is to try to use an object using some other
language.  If you've got some part of MS Office, it's pretty easy to do (VBA).
Or you could try something else, like C# or VB.NET.  You can get free 
dev kits for those, unlike Office.

Matt

6. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at gmail.?o?> Oct 04, 2007
• 720 views

Rad wrote:
> 
> Hi Matt,
> 
> allocate_string() and w32peek_string() gave the same results as before.
> Trying 2147614729 with peek_string() simply terminates the program.

Yeah, I really didn't think that would work.
 
> I tried out other string returning methods in the ocx which are:
 
<snip>

> and they worked fine returning string values as expected.
> 
> The difference being these methods have only one parameter where as Encrypt
> method has 2 parameters.
 
> Could this difference in number of parameters causing the error?

Possibly.  I've found some objects which require named parameters, and
others that fail if you use them.  Did you try calling everything by name:

OCString = invoke( OC6, {"EncryptString", "Key", "InString"},
                   {pBstrAppId, pBstrOCStr},
                   {VT_BSTR, VT_BSTR}, DISPATCH_METHOD )

> 
> Following is the discussion with the developer of 1Crypt ocx:
> =============================================================
> Hi Rad,
> 
> 1Crypt uses only VT_BSTR strings. These are Unicode strings with a maximum
> length
> of 2GB.
> 
> 2147614729 decimal = 80020009 hex
> 
> I'm wondering if this value could be a pointer to a string rather the string
> itself.

No.  It's the error code returned by the object.  Basically, any COM call
returns an HRESULT, which is zero on success, and non-zero when there is
an error.  This wiki link below does a reasonable job at explaining the 
meaning of the bits of an HRESULT, and you can take a look at comerr.ew 
to see a comprehensive list of error codes.  You'll usually see them in 
a hex representation (i.e., #80020009).

http://en.wikipedia.org/wiki/HRESULT

Invoke does some work for you when you get a successful call, since usually
you just want to use the result.  It will automatically read a string value
or a whatever-value.  You're probably not interested in the details, but
can look at the code if you're really interested.  It will, however, 
return the error code when there is one.

> 
> Unfortunately the revised ocx is giving the same result as previous one. 

Is OneCrypt open source?  Or maybe a demo version I could take a look at?

Matt

8. Re: EuCOM : Attn Matt : String Return Value

• Posted by Rad <radhx at re?iffm?il.com> Oct 04, 2007
• 706 views

> Matt Lewis wrote:
> Possibly.  I've found some objects which require named parameters, and
> others that fail if you use them.  Did you try calling everything by name:
>
> OCString = invoke( OC6, {"EncryptString", "Key", "InString"},
>                   {pBstrAppId, pBstrOCStr},
>                   {VT_BSTR, VT_BSTR}, DISPATCH_METHOD )
>

Yes I tried, but it gave following error:

with invoke( OC6, {"EncryptString", "Key", "InString"},
same error as before returning numeric value 2147614729


with invoke( OC6, {OneCryptA_m_EncryptString, "Key", "InString"},

D:\EUPHORIA\EuCOM\eucom.ew:970 in function invoke() 
sequence to be poked must only contain atoms 
    obj = 3
    dispnames = {
                  201,
                  {75'K',101'e',121'y'},
                  {73'I',110'n',83'S',116't',114'r',105'i',110'n',103'g'}
                }
    args = {791276,17698932}
    argtypes = {8,8}
    disp_method = 1
    c = 0
    ok = {49751048,49177269}
    dispid = 201
    retval = <no value>
    bstr = <no value>
    iid = <no value>
    pDispParams = 735700
    mset = 726148
    pVarResult = 735564
    rgvarg = 785060
    pExcepInfo = 801140
    puArgErr = 719300
    rdispidNamedArgs = 729412
    dummy = <no value>
    riid = <no value>
    rgszNames = <no value>
    rgDispId = <no value>
    this = 49751048
    pvtbl = 49177269
    params = <no value>
    source = <no value>
    desc = <no value>
    dispargs = {
                 {73'I',110'n',83'S',116't',114'r',105'i',110'n',103'g'},
                 {75'K',101'e',121'y'}
               }
    i = <no value>
    i = <no value>
    i = <no value>
    i = <no value>

... called from D:\EUPHORIA\EuCOM\OneWay60.exw:315 in procedure proc_onecrypt()


> Is OneCrypt open source?  Or maybe a demo version I could take a look at?
>

It is available for download as shareware from
http://www.atma-software.com/1crypt/index.html

Regards,
Rad.

10. Re: EuCOM : Attn Matt : String Return Value

• Posted by Bernie Ryan <xotron at blu??rog.com> Oct 04, 2007
• 703 views

Rad wrote:

> It gives follwing error:
> 
> D:\EUPHORIA\EuCOM\unicode.ew:176 in function peek_bstr() 
> A machine-level exception occurred during execution of this statement 
>     bstr = 2147614733
>     len = <no value>
> 
> ... called from D:\EUPHORIA\EuCOM\OneWay60.exw:321 in procedure
> proc_onecrypt()

Rad:

Looking at the help file the author says that to use this with vb.net

I wonder if the value being return is the address of a vb string

object and you need to use string oop class to access the returned string.

Bernie

My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API 

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

12. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at ?mail.com> Oct 05, 2007
• 721 views

Rad wrote:
> 
> It is available for download as shareware from
> http://www.atma-software.com/1crypt/index.html
> 

This is really strange.  I can get all of the members to work, except for
EncryptString and DecryptString.  Both of those give an error, and they
crash if you call any combination of the two multiple times.

It all worked fine using VBA and C#.  But now it gets really weird.  If I
translate using Watcom (OW1.7) then it works.  I tried wrapping the COM
calls and translating to a dll, then using open_dll, etc, and if I run
my onecrypt.exw using the interpreter, then it doesn't work.  If I 
translate it and call the dll that way, then it works.  This makes no
sense to me.

Perhaps the author could explain it.  Are we (the calling application) 
expected to instantiate some interface?  I tend to doubt this.  

I thought that maybe there was some difference between the way it was 
being called when translated vs interpreted (not that I could imagine
what that difference might be), but I figured that by putting all of
that code into a dll (i.e., eucom.ew, onecrypt.ew) that the problem
would resolve itself.  But apparently not.  It's a truly bizarre thing
that I can't explain.

Matt

14. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at gmail?c?m> Oct 05, 2007
• 733 views

Bernie Ryan wrote:
> 
> If you look at the docs it says returns TYPE string not BSTR ?

No, this isn't the problem.  When a COM object says "String" it means
that it returns a variant with type VT_BSTR.  It's not the return value
that's the problem.  Something is going wrong inside the actual execution
of the function.  Like I said, 
 
> Also it has a output property of either HEX or BINARY maybe this
> has to be set before calling. 

Nope.  Here's the test code I tried:

include onecrypt.ew
com_err_out( 2 )

constant
oc = create_com_object( OneCryptA_clsid_ix )

? invoke( oc, {OneCryptA_p_HexEncryptStrings, DISPID_PROPERTYPUT}, {-1},
{VT_I4}, DISPATCH_PROPERTYPUT )
? invoke( oc, {OneCryptA_m_EncryptString}, alloc_bstr("secretkey") & alloc_bstr(
"hello world" ),
	{VT_BSTR, VT_BSTR}, DISPATCH_METHOD )

? invoke( oc, {OneCryptA_p_HexEncryptStrings, DISPID_PROPERTYPUT}, {0}, {VT_I4},
DISPATCH_PROPERTYPUT )
? invoke( oc, {OneCryptA_m_EncryptString}, alloc_bstr("secretkey") & alloc_bstr(
"hello world" ),
	{VT_BSTR, VT_BSTR}, DISPATCH_METHOD )

puts(1, "Done.\n")
? getc(0)

When run (exwc onecrypt.exw), I get this output:
C:\euphoria\Development\test>exwc onecrypt.exw
IUnknown::QueryInterface
Found implemented interface: 814C81E6-A9E4-451E-9124-63F0910279A7

IUnknown::QueryInterface
Found implemented interface: 814C81E6-A9E4-451E-9124-63F0910279A7

0
80020009: Exception occurred.
Exception Source:
Exception Description:
2147614729
0
[at this point, it crashes from within the OneCrypt ActiveX, as confirmed
by using trace(3)]

But watch this:
C:\euphoria\Development\test>ecw -con onecrypt.exw && emake && onecrypt.exe

17 .c files were created.
To build your .exe file, type: emake
compiling with WATCOM
main-.c
main-0.c
onecrypt.c
eucom.c
eucom_0.c
eucom__1.c
get.c
dll.c
machine.c
w32support.c
misc.c
fptr.c
unicode.c
variant.c
comerr.c
file.c
init-.c
linking
you can now execute: onecrypt.exe
IUnknown::QueryInterface
Found implemented interface: 814C81E6-A9E4-451E-9124-63F0910279A7

IUnknown::QueryInterface
Found implemented interface: 814C81E6-A9E4-451E-9124-63F0910279A7

0
{68,48,70,66,68,55,51,69,55,69,48,48,67,54,69,66,69,51,68,51,49,54}
0
{208,251,215,62,126,0,198,235,227,211,22}
Done.


Again, I can't explain the behavior...

Matt

16. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at gma?l.c?m> Oct 07, 2007
• 729 views

Bernie Ryan wrote:
> 
> Matt Lewis wrote:
> > 
> > 
> > Again, I can't explain the behavior...
> > 
> 
> Matt:
> 
> I'am confused by your alloc_bstr() in unicode.ew file
> Here you call the ansi_to_unicode() and in that function you
> add two extra bytes then when you peek you ignore them
> and return just the string in a sequence.

Yeah, all I'm concerned about is the actual data, not the null terminator.

> str = ansi_to_unicode( str ) & 0
> 
> But on the return of the unicode sequence you are just appending
> a single NULL.

Yeah, there should probably be two nulls appended (that's what you're 
asking, right?).  I'm not sure why I didn't do that.  It's never been
a problem, though.

Matt

18. Re: EuCOM : Attn Matt : String Return Value

• Posted by jacques deschênes <desja at gl?betro?ter.net> Oct 07, 2007
• 723 views

jacques deschênes wrote:
> 
> Matt Lewis wrote:
> > 
> > Bernie Ryan wrote:
> > > 
> > > Matt Lewis wrote:
> > > > 
> > > > 
> > > > Again, I can't explain the behavior...
> > > > 
> > > 
> > > Matt:
> > > 
> > > I'am confused by your alloc_bstr() in unicode.ew file
> > > Here you call the ansi_to_unicode() and in that function you
> > > add two extra bytes then when you peek you ignore them
> > > and return just the string in a sequence.
> > 
> > Yeah, all I'm concerned about is the actual data, not the null terminator.
> > 
> > > str = ansi_to_unicode( str ) & 0
> > > 
> > > But on the return of the unicode sequence you are just appending
> > > a single NULL.
> > 
> > Yeah, there should probably be two nulls appended (that's what you're 
> > asking, right?).  I'm not sure why I didn't do that.  It's never been
> > a problem, though.
> > 
> > Matt
> 
> No Its OK like that as the string is ansi. The unicode string returned by the
> function must have 2 zero.
> 
> Jacques d.

NO. I'M WRONG  the zero is appended to result not the argument. It's time for
some sleep.

Jacques d.

20. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at gm?il.c?m> Oct 08, 2007
• 704 views

Bernie Ryan wrote:
> 
> Matt Lewis wrote:
> > 
> > Yeah, all I'm concerned about is the actual data, not the null terminator.
> > 
> > 
> > Yeah, there should probably be two nulls appended (that's what you're 
> > asking, right?).  I'm not sure why I didn't do that.  It's never been
> > a problem, though.
> > 
> 
> Matt:
> 
> This may cause intermitent exception errors.
> Remember that your peek_bstr() and peek_unicode() depend on two NULLS.

I agree that this should be fixed.  However, I can confirm that it's not the 
culprit in this particular case.

Matt

22. Re: EuCOM : Attn Matt : String Return Value

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.c?m> Oct 08, 2007
• 710 views

CChris wrote:
> 
> Matt Lewis wrote:
> > 
> > Bernie Ryan wrote:
> > > 
> > > Matt Lewis wrote:
> > > > 
> > > > Yeah, all I'm concerned about is the actual data, not the null
> > > > terminator.
> > > > 
> > > > 
> > > > Yeah, there should probably be two nulls appended (that's what you're 
> > > > asking, right?).  I'm not sure why I didn't do that.  It's never been
> > > > a problem, though.
> > > > 
> > > 
> > > Matt:
> > > 
> > > This may cause intermitent exception errors.
> > > Remember that your peek_bstr() and peek_unicode() depend on two NULLS.
> > 
> > I agree that this should be fixed.  However, I can confirm that it's not the
> > 
> > culprit in this particular case.
> > 
> > Matt
> 
> Perhaps could you, at the same time; fix the problem Bernie had recently
> pointed
> out by removing any namespace references to _parts_ of a library
> (w32support.e,
> as its name says, is not a standalone file).

It's not, but IIRC, there was a point where this 

Yeah, I think at one point I had actually included it in the library.  EuCOM
has had an odd history of being more or less decoupled from win32lib.  It's
been a few years since I've touched the code, so I've got to go back in and
see what's what before making any significant changes.

> Because namespaces are not inherited - if we had named packages and the
> ability
> to namespace a package, the issue wouldn't arise at all -, namespacing part
> of a library is a lock on its structure, which is bad coding unless the coder
> also is the maintainer-for-life of said library. Otherwise, something has to
> give: the code which uses the library - which is what just happened - or the
> library itself, whose structure becomes constrained by locks put on it by
> programs
> that use named parts of it, without the library maintainer being necessarily
> aware or informed of it. Internal structures should be black boxes really.

Actually, namespaces will be inherited (and are inherited, for code at the
head of the svn repository) in the next release.  I typically run this 
code, which is probably why I haven't noticed the bug.

I had thought that I'd included the file in question with the library, but
looking now, I see that's not so...I believe that it moved previously from
the tk_* file structure to the w32* structure (which was probably when the
file dropped out of the distribution).  I moved from tk_mem.e to 
w32support.e in v2.06 (previous release) apparently to avoid namespace
conflicts.

Some serious thought needs to be applied to this.  I will likely just
supply a eucom version of w32support.e, likely renamed to remove 
ambiguity.  Of course, this may make it more difficult for people who 
write win32lib based eucom programs.  This will only be a problem for
people using 3.1.* versions of euphoria with v0.70.* versions of win32lib,
which seems to have some other compatibility problems, so maybe the 
best course is to wait and see what happens there first. 

Matt

24. Re: EuCOM : Attn Matt : String Return Value

• Posted by Pete Lomax <petelomax at bl?ey?nder.co.uk> Oct 09, 2007
• 703 views

Matt Lewis wrote:
> 
> Actually, namespaces will be inherited (and are inherited, for code at the
> head of the svn repository) in the next release.  I typically run this 
> code, which is probably why I haven't noticed the bug.

Cool. How did you solve that in the end? In Positive I devised a set of priority
tables, which is quite simple really but harder to explain, eg:

-- fileno  desc       parents	 priorities
--   1	   inc7 	{}	{2,1,1,1,1,1}
--   2	     eric	{1}	{2,4,3,3,3,3}
--   3	       bob	{2}	{2,4,6,5}
--   4		 alice	{3}	{2,4,6,8}
--   5	       diane	{2}	{2,4,4,4,10,9}
--   6		 chris	{5}	{2,4,4,4,10,12}

So in bob (hence using priorities[3]), after alice has been included, if there
are multiple global X then one in file 3 (bob, priority 6) is the first choice,
then one in file 4 (alice, priority 5), then eric, then inc7.
(I trust everyone agrees that is how it should behave.)

Likewise in eric (hence using priorities[2]), after bob/alice/diane/chris have
been included, then if there is an X in file 2 (eric, priority 4), use that, else
if one (*and only one*) in bob/alice/diane/chris, priority 3, use that else inc7.

An include extends the parent(s) with priorities[p,p]-1, eg "include bob"
extends priorities[2] from {2,4} to {2,4,3}, and "include alice" extends
priorities[3] from {2,4,6} to {2,4,6,5} and priorities[2] from {2,4,3} to
{2,4,3,3}. Lots of numbers but quite simple to do in practice.

A new file copies the parent promoting sub-includes to parent priority, eg
"include diane" begins by copying eric's {2,4,3,3} to {2,4,4,4} and adding a new
high priority (simply 2*idx, here 10) for itself, before as above extending
eric's to {2,4,3,3,3} and inc7's to {2,1,1,1,1}. Again this may look more complex
than it is.

For namespace handling, just ignore any files with priority < [p,p]-1, eg
after "include bob as bob", then bob:xx looks up xx using priorities[3], ie
{2,4,6,5} but ignoring anything of lower priority than 5, hence only looking in
bob and alice, not eric and inc7.

No doubt there will be some detractors, but I'm quite proud of that design as it
allows a single pass through the (single) global table, keeping track of the
highest priority and trivially discarding any lower previously found, plus simply
making a note of the priority adds minimal cost to the single instance case.

Whether that scheme could be used in eu.ex is another matter.

Regards,
Pete

26. Re: EuCOM : Attn Matt : String Return Value

• Posted by CChris <christian.cuvier at agr?culture.gou?.fr> Oct 09, 2007
• 723 views

Matt Lewis wrote:
> 
> Pete Lomax wrote:
> > 
> > Matt Lewis wrote:
> > > 
> > > Actually, namespaces will be inherited (and are inherited, for code at the
> > > head of the svn repository) in the next release.  I typically run this 
> > > code, which is probably why I haven't noticed the bug.
> > 
> > Cool. How did you solve that in the end? In Positive I devised a set of
> > priority
> > tables, which is quite simple really but harder to explain, eg:
> > 
> > -- fileno  desc       parents	 priorities
> > --   1	   inc7 	{}	{2,1,1,1,1,1}
> > --   2	     eric	{1}	{2,4,3,3,3,3}
> > --   3	       bob	{2}	{2,4,6,5}
> 
> <snip>
> 
> My technique is a bit different.  I don't worry about priorities.  Just the
> 'lineage' of each file.  Basically, I record who got included by whom.
> Then, when doing a symbol lookup, if there are multiple matching global
> symbols, I have to do some work.
> 
> If no namespace identifier is used:
> 
> I detect if a symbol is within or without the current file's include
> tree.  If there is only one symbol from the include tree, and one or more
> from without, then the one from within is selected.  This resolution will,
> IMHO, solve 95% of the possible namespace conflicts with 3rd party libs.
> 
> If multiple symbols from within are identified, then an error results.  
> 
> If no symbols from within are identified, and multiple from without, an
> error results
> 
> Now, when a namespace identifier is used:
> 
> If a symbol is not within the file (as specified by the namespace identifier),
> 
> *or its include tree* then it is ignored.  If multiple symbols are found,
> then an error results.  
> 
> This could, in theory, break some existing code, but given the dearth of 
> namespacing in today's code base, I doubt that many would be affected. 
> I suppose it is this situation which led you to the priority scheme, and
> which might be useful in this case.
> 
> I suppose that giving preference to a symbol in the namespaced file (as
> opposed to files included by that file) would also work to solve the 
> dilemma.  It would be similar to having local symbols overriding globals
> from other files.  If the user really needed to use the nested symbol,
> then he could include whatever file it was and give it its own 
> namespace.  A corner case, to be sure, but not inconceivable.
> 
> Matt

Does the include tree also contain the direct ancestors? If not, there are some
issues with this scheme, which is quite common:

-- file1.e
include third.e
global integer n_also_in_third
n_also_in_third=n_init() -- ok, this g.s. shadows anything in third.e
include file2.e
--...

-- in file2.e
integer my_var
my_var=n_also_in_third 
-- could produec an error, while   
-- file1.e::n_also_in_third is obviously being targeted

As the name suggests, n_also_in_third is also a global symbol defined in
third.e.
I'd consider it a problem if this isn't properly handled.

CChris