bb.donnay-software.com

I have an activeX control I call that pops an entry screen. When I call it, occasionally it pops as it should (on top). Most of the time it seems to be behind the main app (it shows on the task bar and can by clicked to bring forward).

I would think that there's a way to force it to be on top (It can't be truly modal as it has other screens it calls that go over it).

This is what creates it:
oEasyIntegrator:=ActiveXObject():Create("cipwin32.EasyIntegrator")

Looking thru the xbase board I found a series of posts between Roger and others on a similar issue and tried using that solution (from a bit less than a year ago)... but either it is a different scenario or I have the syntax wrong.

I've tried various permutations and combinations of the following ideas, but they all either crash or freeze at that point in the code.

//SetForegroundWindow(oEasyIntegrator:getHwnd())
// oEasyIntegrator:toFront()
//hWnd:=oEasyIntegrator:getHwnd()
//DLLFUNCTION SetForegroundWindow(hWnd) USING STDCALL FROM user32.dll
//SetForegroundWindow(oEasyIntegrator:getHwnd())

To be perfectly blunt - if you took everything I know about activeX (or most programming things for that matter) and shoved it up a gnat's ass, it would rattle around like a pea in a boxcar!

I would think that some of the above should do what I want, but I can't get the syntax or parameters right. As always, I turn to the 'oracles of all knowledge' for assistance.

thanks,

bruce

I cannot tell from your code what you are using as the parent window.

You may want to put the ActiveX control on a dialog window and then set the dialogwindow:toFront().

I noticed that you posted this message in the eXpress++ forum instead of the Xbase++ forum.

Do you use eXpress++?

It appears that you don't, otherwise you would probably be using the @ .. DCACTIVEXCONTROL command.

Roger:

We have been using express for many years - you've been invaluable in assisting us many times. With my not understanding activeX at all, a while ago I posted on your old board for help and one of your kind members wrote the basic calls for us. I modified his code to add other things we needed. He didn't use express in that.

In the original situation, the activeX control was a single window that popped up over our app (over the sales screen) and in that mode the activeX loaded modally. Now I need to use other functions of the control and those cannot have the control load modally as it has other windows that can overlay it.

I have nothing specifically defined as a parent window. My setup at present is that I have a modal dalog window that pops up over the main app window, that dialog window has an ok button to close it. I added another button that closed the modal window then called the activeX control (I figured that I had to get rid of the modal dialog box otherwise the object couldn't appear on top).

I would prefer to convert to express handling of things as your stuff is ALWAYS easier then native xbase. I'll look at your sample code and see if I can follow it.

If I put the activeX control on a dialog window, then that window would show aound the control? Or could the dialog window be created invisible? As I've said several times in the past, I'm really a novice at all of this. I've gotten pretty good at blocking, copying, and modifying code - but I really don't understand much behind it. Without a 'close' button on the background window, how would the window get closed when the activeX control closed?

thanks,

brue

Brue -

There are tons of examples of DCACTIVECONTROL under \exp19\samples.
The below code will create an instance of the ActiveX control and put it on a dialog window.
Resizing the dialog will also resize the ActiveX window.
When you destroy the dialog it will also destroy the ActiveX window.

What is Easy Integrator?

Roger

Thanks, i'll try it in the next few days when I have a few minutes free.

EasyIntegrator is credit card processing (product is ChargeItPro) we've integrated into our POS app . The basic sales part has been working great for a year or longer (thanks to the assistance of your board). Now, with tighteer security restraints, we're forced to change the way we hasndle those situations where a merchant keeps a credit card on file.

The focus problem relates to their entry screen(s) for remote and secure storae of cc info (rather than locally as we did before).

If anyone is looking to integrate credit card processing into their app I H I G H L Y recommend ChargeItPro. They have been wonderful to deal with.

thanks,

bruce

That sounds like a good solution to the CC storage problem.
I will look into it.

I've played with it for a few minutes (not too much yet). Looking at your DCACTIVEX documentation it says that it works with any method supported by the XbpActiveXControl(). I think that means setting the properties and calling methods as in oEasyIntegrator:{property} := 'Something'

What I have for those are:

oEasyIntegrator:LoadSetup(SetupString)
trans := oEasyIntegrator:getProperty('TransFields')
trans:AmountTotal := 4 // test sale amount
oCustomer := oEasyIntegrator:getProperty('Customer')
oCustfields := oCustomer:getProperty('CustomerFields')
oEasyIntegrator:Customer:CustomerFields:Clear()
oCustfields:FirstName := fname //'G.C.'
oCustfields:LastName := lname //'Maxwell'
oCustfields:Company := cmpny //'E=mc2'
oCustomer:UpdatePayments(cip_id) // 50243
StringSavedCustomerRef = oEasyIntegrator:Customer:CustomerRef
cip_id := StringSavedCustomerRef

I tried putting that code block before and after the dcread gui. After popped up the dialog window, but no easyintegrator. Before didn't do anything. Is there a parameter for the dcactivex that these should be put into? They worked fine in the native xbase function (except for the focus issue). Here's the whole function that works:

procedure Call_CIPNET1(cip_id)

Local oEasyIntegrator, ret_val:=.f., GetList[0], GetOptions
local SetupString:='',nVar:=1
local trans
local oCustfields
local oCustomer
local StringSavedCustomerRef:=''

SetupString:=GetCIPsetup(nVar)

if !(ValType(oEasyIntegrator)) == 'O'
oEasyIntegrator:=ActiveXObject():Create("cipwin32.EasyIntegrator")
endif

IF NIL == oEasyIntegrator // test to see if it got created
msgbox( "Error: " + Chr(13) + Chr(10) + "Description: " + ComLastMessage() )
//MsgBox( "Description:" + ComLastMessage() ) // show error message if not
RETURN //StringSavedCustomerRef
ENDIF

oEasyIntegrator:LoadSetup(SetupString)
trans := oEasyIntegrator:getProperty('TransFields')
trans:AmountTotal := 4
oCustomer := oEasyIntegrator:getProperty('Customer')
oCustfields := oCustomer:getProperty('CustomerFields')
oEasyIntegrator:Customer:CustomerFields:Clear()
oCustfields:FirstName := fname //'G.C.'
oCustfields:LastName := lname //'Maxwell'
oCustfields:Company := cmpny //'E=mc2'
oCustomer:UpdatePayments(cip_id) // val(cip_id) )//'0') //43234 //50243
StringSavedCustomerRef = oEasyIntegrator:Customer:CustomerRef
cip_id := StringSavedCustomerRef
// msgbox(StringSavedCustomerRef)
return

If you're interested in CIP, call Phil Telesco at (800)989-2135 (www.ChargeItPro.com) He's great to deal with!

On a different subject: I noticed that you created a function and returned 'nil' rather then making it a procedure. Is there a reason for that? I heard somewhere from someone (don't remember details) that a procedure will slightly run faster than a fdunction because it doesn't have to return anything. Is there any truth to that or is function/procedure selection merely a personal choice?

You need to call the code in the EVAL clause of DCREAD GUI.

mucho thankso.... i'll play with it tomorrow afternoon when I get back in.

Roger....

Getting close! It basically works, except the background window doesn't cose when I close the easyintegrator. I wonder if easyintegrator doesn't actually completely close, but stays in memory. I emailed them about that.