PressButton(HC OK) problem and Debugger

Zoltán ,

I suggest you follow Darren's suggestion and pull the needed code into a BSFN. We all know how much time can be lost chasing issues like this.

Good luck Friend,

Hi Larry,

There is two reason why do not put the needed code into a BSFN:

1.) Tranaction processing is required and events, where transaction processing is available is limited. These are the OK button events and the *DB Before, *DB After events. OK events do nott run and the others run only after OK Button Clicked, so they also do not run. This is the ptfall of 22.

2.) If I press the Cancel instead of OK, then the situation is the same. The form does not return. If I run with debug, then Cancel returns too.

So, how to return without debugger?

Regards,

Zoltán

Zoltan,

Is the ER where you do this from in the same Form as which OK button you are trying to click?

What, I suspect, is happening is that your call becomes recursive: the ER is still in progress when you clicking the button and your own process is preventing it from functioning by deadlocking it.

What I suggest you do, if that's the case, is to finish your ER with a call to an external program, which would in turn click the OK button - _AFTER_THE_ER_HAD_FINISHED_. This way you may have a chance.

To try this idea, I am attaching a command-line executable, which accepts one parameter - the "lpBhvrCom->hDlg", from what Darren has suggested. It then executes the same "PostMessage" call as his BSFN - only this time, it will be called _outside_ of the ER. Just execute a call an external program call, passing the lpBhvrCom->hDlg, converted to string, as the only parameter. Make sure that you call this command as the last statement in your ER, in order that it finishes _before_ the external program runs. If the external command call is synchronous, you may need to also create a couple of batch files, so that the one you call from ER would spawn the second one with a "start" and terminate, returning control back to the ER:
|
:: First Batch will call the Second Batch in a separate thread:
start BATCH2.CMD %1
:: and then terminate, returning control back to the ER
|
while the second batch should call "sleep" to pause for a second, waiting for the ER to finish and then execute the attached EXE:
|
:: The second batch will pause for a second:
sleep 1000
:: and then call the ClickOK program, passing the parameter along:
ClickOK %1
|
The lpBhvrCom->hDlg parameter should be passed from call to call along this chain.

This may sound a bit convoluted, but so are your requirements ;-)

Hope, this helps.

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Hi List!
És Üdv, Zoli!

Reading this thread (and some earlier ones) a strange thought occured to me... Is it possible that the synchronous/asynchronous execution is handled differently with debub on than with debug off?
I noticed that quite many OK post button clicked problems were reported to run correctly with debug on while if they were run normally the synch/asynch threads got mixed up...
Is it possible that Zoltán is having a similar problem?
Regards:
Gergely Pongrácz
e-Best, Hungary

Hi List,

és üdv Gergõ!

The asynchronous execution and debugger issue is a very well known issue for me for a long time.

The first thing, what I had done was to turn off Asynchronous execution for all BSFN call in the OK Post Button Clicked.

Further I moved all logic from all *Asynch event to the In-line equivalent event.

Regards,

Zoltán

Zoltan,

Did you have a chance to try the little tool I posted? I'm keen to know the results...

Since it works outside of OW, I would expect it to solve your issue.

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Ok, then let's press that button in a new thread. . . .


Try this in your new bsfn:

void __cdecl newThread( void *lpBhvrCom );

/**************************************************************************
* Business Function: BlahBlah
*
* Description: Blah
*
* Parameters:
* LPBHVRCOM lpBhvrCom Business Function Communications
* LPVOID lpVoid Void Parameter - DO NOT USE!
* LPDSD5501 lpDS Parameter Data Structure Pointer
*
*************************************************************************/

JDEBFRTN (ID) JDEBFWINAPI BlahBlahLPBHVRCOM lpBhvrCom, LPVOID lpVoid, LPDSD5501 lpDS)
{

. . . . .~~~~ snipped to safe space ~~~~. . . . . .

_beginthread( newThread, 0, (void*) lpBhvrCom );

/************************************************************************
* Function Clean Up
************************************************************************/

return (ER_SUCCESS);
}

/* Internal function comment block */
/**************************************************************************
* Function: Ixxxxxxx_a // Replace "xxxxxxx" with source file number
* // and "a" with the function name
* Notes:
*
* Returns:
*
* Parameters:
**************************************************************************/

void __cdecl newThread( void *lpBhvrCom )
{
LPBHVRCOM lpBhvrComThread= lpBhvrCom;
/* wait for 3 seconds */
Sleep( 3000L );
/* Send a Button Press to the originating program */
PostMessage(lpBhvrComThread->hDlg,WM_COMMAND,LOWORD(CONTROLID_OK);
/* End the tread */
_endthread();
}

Darren,

This may not be enough: the ER will still be in progress, plus this new thread will still belong to the same process.

I think, if that's the right direction, then my tool would have a better chance: if called in the last statement in the way I have suggested, it will fire 1) after the ER has finished and 2) from a different process.

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Well, that's why I put a 3 second delay in. Of course he could extend that to 10, or whatever. My point here is to get a thread that isn't interacting with the spawning thread, but waits some amount of time.

In my opinion, the external program is too messy. I like my work to be completely inclosed in the system (i.e. running program). Just my preference, I guess.

Sorry, I missed the delay. True, this may be better.

I'm keen to know the results...

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Hi Darren,

GREAT!
IT WORKS!!!!!

The solution came in the last minute.

Thanks a LOT!

I will reply later a bit longer, sharing my observations - but I am currently very busy.

THANKS AGAIN,

Best regards,

Zoltán

Hi List,

I would like to thank to everybody, who tried to help me in this issue.
Thanks!

Of course, first of all to Darren (WhippingBoy).

Regards,

Zoltán

Alexander,

Excuse me, that I didn't try your suggestion.

As you know, Darren's solution solved my problem and it was a bit easier for me.

Thanks for your help anyway!

Regards,

Zoltán

Hi Darren,

First of all, THANKS A LOT!

I promised, that I will be reply a bit longer.

It worked with the first attemp.

Next time I tried without delay and with 1 ms delay. Neither worked.
I was just curious, that does it work with the separate thread execution alone?

I suppose, to press the OK is not required in the BSFN.
It is just enough, that the BSFN "sleeps" enough long in a separate thread. After the return the BSFN you can simply press the OK from ER.

I tried something "separate thread" but not this way of C code.
I called a BSFN to wait, called an other form to wait, but I suppose, all executed in the same thread. I had an other idea, to call a form Modeless mode, but unfortunately you can do that from an update capable form.

In my final solution, I do not call your BSFN on the data entry transaction form, instead of I call a Message form, without System Menu and with a hidden OK button.

The title is somethig like "Please, be patient..."
The text on the form is somthing like: "The application is waiting for the termination of the event execution"

The customer can not interact with this form (no System menu, OK is hidden). I call your magic BSFN with 10 sec delay from the Dialog is Initialzed.

I call this form right before my OK logic.

I can not say enough THANKS to you!

Best regards,

Zoltán

Hi Eric, Christian and JDEList Admins,

Is it possible to place Darren's (WhippingBoy) brilliant solution onto the Tips & Traps board?

Regards,

Zoltán

Zoltan,

I will forward your request to Eric.

Lee Stilleke
Director of Support, JDEList.com

Zoltan_Gyimesi wrote:

Fair enough. Conceptually, it's the same idea, just different implemetation...

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Servus Zoltán

I must admit I haven't been following this thread and would struggle to document the outcome into the tips section other than copying the entire thread. I'd need to go through a few bottles of Eger Bikaver to accomplish the summation.
Are you (or Darran or anybody else) able to summise the findings and send it to my e-mail address ([email protected])? I'll take care of the rest.

Rgds,