1. RE: EuCom
Good question! Several reasons:
1. Because it was "there" and I needed to clibm that mountain.
2. I wanted a grid control that would be native to Euphoria/Windows.
3. I could add whatever features I wanted to a custom written control.
4. Matt has done a good job so far with EuCom but if you look at the
current trends in computer programming technology MS might soon abandon
COM in order to push everyone to .NET. My control uses standard windows
apis which I doubt will go away any time soon.
Jonas
10963508 at europeonline.com wrote:
> So Matt is on holiday I guess.
> For anyone intereseted, to use SHEET.EXW you have to first register
> sgrid.ocx.
> You do that with this:
> regsvr32 sgrid.ocx
> Jonas, this sheet demo looks same to your control, I'm just interested,
> why
> did you write your own control?
> I'll try to debug eucom a little we'll see how succesfull ill be.
>
> ----- Original Message -----
> From: <10963508 at europeonline.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Saturday, July 13, 2002 11:57 AM
> Subject: Re: EuCom
>
>
> > I'll also need to have Internet Explorer browser control in my program,
> > that will also require EuCom's help. Anyone done this already?
> > These things would be easily done
> > within Visual Basic or Visual C++, so will I have to switch to them?
> >
> > ----- Original Message -----
> > From: <10963508 at europeonline.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Saturday, July 13, 2002 10:29 AM
> > Subject: EuCom
> >
> >
> > > To Matt Lewis,
> > > I wanted to use ADO to access .mdb files because it is simpler and
> faster
> > > than
> > > ODBC.
> > > With TBROWSE.EXE I generated msado15.ew for file C:\Program Files\Common
> > > Files\System\ado\msado15.dll.
> > > I was really surprised it generated wrapper for me automatically.
> > > I then run program which has only this line:
> > > include msado15.ew
> > > (I copied all include files from EuCom to my program's directory)
> > > and it gives me this Windows error:
> > > "The instruction at ... referenced memory at ... Memory could not be
> read
> > > from."
> > > I then tried it with another file, msadox.dll, and it displayed the same
> > > Windows error.
> > > I am using WinXP, EuCom v2.0a.
> > >
> > > Matt, if you could fix this bug then EuCom would really be useful!
> > >
> > >
> > > By the way,
> > > I try to run SHEET.EXW and Interpreter gives me this error:
> > >
> > > C:\EUPHORIA\samples\OLD ON CD ALREADY\eucom2a\activex.ew:672 in function
> > > get_ax_obj_ix()
> > > subscript value 0 is out of bounds, reading from a sequence of length 0
> > > ax_ix = 0
> > >
> > > ... called from C:\EUPHORIA\samples\OLD ON CD
> > ALREADY\eucom2a\activex.ew:869
> > > in function get_handle_ax()
> > > ax_ix = 0
> > > obj_ix = <no value>
> > > ok = <no value>
> > > this = <no value>
> > > pwindow = <no value>
> > > phwnd = <no value>
> > > hwnd = <no value>
> > >
> > > ... called from C:\EUPHORIA\samples\OLD ON CD
> > > ALREADY\eucom2a\activex.ew:1155 in procedure set_visible_ax()
> > > ax_ix = 0
> > > visible = 0
> > > hwnd = <no value>
> > > ok = <no value>
> > >
> > > ... called from C:\EUPHORIA\samples\OLD ON CD
> ALREADY\eucom2a\SHEET.EXW:41
> > >
> > >
> > > Tone ©koda
> > >
> > >
2. RE: EuCom
> -----Original Message-----
> From: 10963508 at europeonline.com [mailto:10963508 at europeonline.com]
> To Matt Lewis,
> I wanted to use ADO to access .mdb files because it is
> simpler and faster
> than
> ODBC.
> With TBROWSE.EXE I generated msado15.ew for file C:\Program
> Files\Common
> Files\System\ado\msado15.dll.
> I was really surprised it generated wrapper for me automatically.
> I then run program which has only this line:
> include msado15.ew
> (I copied all include files from EuCom to my program's directory)
> and it gives me this Windows error:
> "The instruction at ... referenced memory at ... Memory could
> not be read
> from."
> I then tried it with another file, msadox.dll, and it
> displayed the same
> Windows error.
> I am using WinXP, EuCom v2.0a.
>
> Matt, if you could fix this bug then EuCom would really be useful!
Sorry, didn't check my email over the weekend. I've never tried to wrap ADO
before (I've done Access itself, though). I'll check this out and see what
I can come up with. I'll also look into IE for you.
Matt Lewis
3. RE: EuCom
> -----Original Message-----
> From: Tone 10963508 at europeonline.com [mailto:10963508 at europeonline.com]
> procedure test_odbc_speed ()
> atom t1
> object sr_data
> STRING guid
>
> sr_data = execDirectODBC (H_Fazzt_Conn, "SELECT * FROM
> SelectiveReception")
> if not sequence (sr_data) then
> odbcError (-sr_data)
> return
> end if
>
> puts (1, "start test\n")
> t1 = time ()
> for i = 1 to length (sr_data) do
> guid = sr_data [i] [SR_GUID]
> Void = execDirectODBC (H_Fazzt_Conn,
> "UPDATE SelectiveReception SET Ignore = 2 WHERE
> (GUID = '" &
> guid & "')")
> end for
> ? time () - t1
> end procedure
I assume this is just an example, because you could really speed this query
up simply by running the query:
"UPDATE SelectiveReception SET Ignore = 2"
There are some more general things you can do to speed up processing.
Although I never wrote a nice wrapper for it, you'll want to use
SQLPrepare/SQLExecute for your UPDATE. It will save time parsing. You'll
need to use a parameter (SQLBindParameter) for GUID, and set that each time.
I suspect that the total volume of hard drive access isn't really any
different for either case.
SQLBindParameter allows you to set up a buffer for a parameter and poke the
value in. You don't need to do any sort of parsing each time to run the
query. All of the functions and constants should already be declared in
odbc.ew. So something like this:
-- start code
atom hstmt
hstmt = allocHandleODBC( SQL_HANDLE_STMT, H_Fazzt_Conn )
atom sql_ptr
sequence sql
sql = "UPDATE SelectiveReception SET Ignore = 2 WHERE GUID = ?"
sql_ptr = allocate_string(sql)
-- the ODBC driver will parse the query here
VOID = c_func( SQLPrepare, {hstmt,sql_ptr,length(sql)+1})
free(sql)
-- sr_data is the result of your query
guid_ptr = allocate_string(sr_data[1][SR_GUID)
strlen_ptr = allocate(4)
poke4(strlen_ptr( length( sql ) + 1 )
-- bind guid_ptr to the '?' in the SQL statement
VOID = c_func(SQLBindParameter,{hstmt,1,SQL_PARAM_INPUT,
SQL_C_CHAR,SQL_VARCHAR,length(sql)+1,0,guid_ptr, srtlen_ptr})
for i = 1 to length(sr_data) do
-- updates the parameter each time
poke(guid_ptr,sr_data[i][SR_GUID)
VOID = c_func( SQLExecute,{hstmt})
end for
-- end sample
You may need to play around with some of the parameters passed to
SQLBindParameter:
From:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/od
bcsqlbindparameter.asp
SQLRETURN SQLBindParameter(
SQLHSTMT StatementHandle,
SQLUSMALLINT ParameterNumber,
SQLSMALLINT InputOutputType,
SQLSMALLINT ValueType,
SQLSMALLINT ParameterType,
SQLUINTEGER ColumnSize,
SQLSMALLINT DecimalDigits,
SQLPOINTER ParameterValuePtr,
SQLINTEGER BufferLength,
SQLINTEGER * StrLen_or_IndPtr);
Matt Lewis
4. RE: EuCom
10963508 at europeonline.com wrote:
> Yes that was just example, in reality I need to go thru every
> record in
> table from first till last and check some fields, and depending on
> value of
> those fields set value of other field in same record. That's all I
> want to
> do.
Maybe there's a slick SQL way to do it. If you want to email me
privately (use matthew.w.lewis at saic.com right now, I can't get into my
yahoo account today), I can maybe help you.
> And I can't do it in Euphoria, ODBC API is so complicated it's
> driving
> me nuts :(. Lost whole week trying to figure it out.
> MFC wrapps ODBC API with 4000 lines file, that gives you idea how
> complicated is ODBC API.
> I thought about wrapping MFC dll, but MFC uses C++ classes so how
> would that
> work?
Ughhh...
> Your example probably wouldn't speed things much up as you said,
> but using
> SQLSetPos with SQL_UPDATE would.
Maybe. If I get a chance, I'll test it to see what the speed difference
is.
> I have this C++ code (below, it's easier in this case to test it in
> C++) and
> it doesn't work, last SQLSetPos() fails. It gets correct data from
> table,
> but it's unable to update it with new data. I followed example and
> instructions from MSDN exactly and it still doesn't work :(.
I don't know what to tell you about that. But I've had similar
experiences with other tests. :)
> Now I have these options:
> - Write this whole part in C++ and make dll out of it (I can't use
> ADO in
> C++(had some problems), so I would need to use MFC, complications
> again).
> - You will fix EuCom and I will use ADO.
> (BTW Eucom crashed with Windows error on WinXP and other
> computer which has Win98 installed when I run comtest.exw.)
I tried your simple test on Win2000, and got a crash. Then I included
eucom before including the ado wrapper, and it didn't crash (although
there were some errors). I haven't had a chance to thoroughly
investigate the situation, but here are some tips:
- Make sure you wrap ado as an ActiveX object (because it is).
- You'll need to change calls to get_dispid() to register_dispid().
- If you actually plan to use the result of these calls, you'll need to
add the VT_ codes for the parameters.
In general, I've found that I only use the top level objects this way.
Most other objects get passed to you through other calls, and I've found
it easier to use the invoke_ptr method of calling things. I'll try to
get a working demo out here shortly.
Matt Lewis
