PressButton(HC OK) problem and Debugger

[Zoltan_Gyimesi]

Hi JDEList/Forum,

I copied P4114 appl to a custom one, to prepare it for automated upload.

My main screen call W4114A Inventory adjustment through the Add button of the W4114B Work With form, to call the Headerles/Detail form in ADD_MODE.

I load the fields on the Header(less part of the Form and load the grid with some record. After I done, I press the OK button from Event Rule.

The problem is that the ER of OK does not started at all.
When I build the debug info in OW debugger and started the debugger before to call my APPL, then it works fine.

I already tried everything, eg.:

- removed all asynch executions
- marked the form to "End form on add"
- I call the OK two times to skip Warnings
- I repeat the ER logic of Cancel events on the end of Post OK (marking the BSFN call to Include transaction)
- I place my logic into several place together and splited too
- I move all Async event logic onto the end of In-Line events
- created a work table inserting record for all events which will be run (separately for rows) when I insert grid buffer. I also insert record into WF in In-Line event. I delete the appropriate record at the and of the event. Tried to check the table several modes, inside the form, in a called outer form, etc. (all WF manipulation are encapsulated into a single BSFN)
- I added Wait x Seconds before and after check the WF
- I created a form in a separate APPL which "Find" the WF whilel it is not empty and returns when empty
- counting down the events and tried to check the counter
- marking the last inserted row and check when the event of it ends
...and tried several other

unfortunately without success.

If I do not run the debugger:
A.) then the OK does not started
B.) Or the APPL hangs up on a dead-lock loop.

I have to call this copied APPL and some more copied Inventory APPL in a loop and do not pass the control to the user while Error does not occur or the process ends.

Building debug info and run the debugger before starting the APPL is not an end-user friendly solution and it is not really an appreciatable solution. However starting the debugger is automated in the current state.

Any idea, tip will be highly appreciated.

Regards,

Zoltán

 

[lefab]

Can you put a table I/O (for example insert) in the first line of Ok button ER to see, without debugger, if the first line is executed.

Other stuff is that all row exit events will be processed before Ok ER. Be shure that no Stop processing ER is encontered.

Also, be carefull that no button is defined as default push button.

 

[Zoltan_Gyimesi]

Hi Fabien,

Thanks for your answer!

>> Can you put a table I/O (for example insert) in the first line of Ok button ER to see, without debugger, if the first line is executed.

I did somthing similar. I placed a new control onto tthe form and I assigned a value to it, in the first line of Button Clicked event of OK. The control remained empty and cursor returned to the user.

>> Other stuff is that all row exit events will be processed before Ok ER.

I know, all Exited etc. events will be processed before OK ER. When I run the debugger, OK executes fine and return the application. When I do not run the debugger, then the user gets back the cursor and the appl remains on the form and no OK processing happens.

>> Be shure that no Stop processing ER is encontered.

In some of my previous versions I didn't use Stop Processing statement, but in the current. I re-organized my logic without this statement. Unfortunately, it did not help However the copied application still contain some Stop Processing statement in some Menu/Toolbar exits in the Row menu, but they do not run at all. I suppose these are "innocent".

>> Also, be carefull that no button is defined as default push button.

No of my Push Buttons is Default. The copied form does not contain visible or non-visible button, so the form does not contain Default button. Further, as far as I know, we can not mark Menu/Toolbar Exits Hyper Controls as Default. Am I right?

Thank you again anyway?

JDEList, other hint or suggestion?

Regards,

Zoltán

 

[Mali]

Try putting the code at "Add last entry row to grid"
Have you used the same form type in your previous applications similer to this?

 

[DBohner-(db)]

Zoltan,

What form-type is it? My brain escapes me, but isn't there a form type that ER in the OK button doesn't function? The work-around is to create a custom OK button and hide the default.

Daniel

 

[Zoltan_Gyimesi]

Hi Mali,

Thanks for your hint.

I have already tried to put my logic there and in many other place without succes.

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Mali,

This APPL is a copy of the P4114 appl and the type of the form is Headerless/ Detail

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Hi Daniel,

Thanks for your response.

As I mentioned earlier, this APPL is a copy of P4114 Inventory Adjustment. The type of the problematical form is Headerless/Detail.

I can not move the logic to a "Custom OK", because Transaction Processing won't work there, and Transaction processing is reequired.

The problem is not, that OK button doesn't function.
When I hit the OK from ER then the OK process do not started at all and the user get the control of the appl.

The goal of my task, is to enter Inventory transaction into OW from outside automatically (say interface).

The copied P4114 is called more times in a cycle from an other, frame application to enter more transaction in one "run", without user interaction. It should be stopped only, when error occurs.

When debug info is build for the appl and debugger has been started previously, the it works fine and the copied appl executes the OK process and returns to the caller application.

Any other hint?

Regards,

Zoltán

 

[WhippingBoy]

Maybe I missed it, but which event presses the OK button?

 

[Zoltan_Gyimesi]

Hi Darren,

I pressed the OK button several ways while I tried to solve the problem:

- Post Dialog is Initialized
- Add Last Entry Row to the Grid
- Last Grid Record had been Read
- on the detected last Row Exited & Changed
- Control is Enetered
... maybe somewhere else events/tricky way too


I placed the Press OK into the Event of a new Push Button (Terminate) and Pressed this button on the same places.

I am out of ideas

Regards,

Zoltán

 

[Mali]

Can you Give the event Rule Listing of the following as an attachment

"I load the fields on the Header(less part of the Form and load the grid with some record. After I done, I press the OK button from Event Rule. "

How & where do you do this? That will give us a better understanding. When you say automated uploading I think you are populating the field from another table & trying to write to a different table. I don't think disabling "Page at a time time Processing" will help you in this case.

 

[WhippingBoy]

What's this thing?

- I added Wait x Seconds before and after check the WF

I can't help but think that the BSFNs are still 'in process' somewhere and you're hitting the 'in process' error that disables the OK button.

I've never been particularly successful with what you're attempting. Automating entire programs isn't what the tool does, so I always take the ER down to a new BSFN and do the work in there.

Now, if you're determined to make this work we may need to get really fancy and try 'delay' bsfns, or something. These guys aren't running HTML, or citrix, or anything like that are they?

 

[Zoltan_Gyimesi]

Hi Mali,

Thanks for your interest!

I have also tried "Disabl Page-at-a-time Processing" without succes.

I think, there is no need to send ER list.

Place the PressButton(HC &OK) statement onto the end of ER in Post Dialog is Initialized event of P4114 / W4114A form.

Place a control without edit rules (e.g. DL01) onto the form.

Assign a value to the control in the first line in the Button Clicked event of OK button.

Mark the End Form on Add check-box (Form / Properties / Options).

Call the debugger, select P4114 to debug, build the debug info for P4114.
Exit debugger.

Run the application, press Add on the entry form and see what happens (DL01 get the assigned vallue and / or the form returned?)
Exit the appl.
Start the debugger (do not place break points).
Run the application again, press Add on the entry form and see what happens.

I am really curious for your result.
(Maybe other can make this experiment too and post the results here).

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Hi Darren,

Thanks your interest too!

Playing with WF (Work File) and Wait x Seconds were some of my try-outs in my despair. This codes are alreday removed from the appl.

Please, check my previous post to Mali, how to reproduce the problem.

I am on FAT client, and no Citrix, HTML, etc.

When I detect the differenc of the behaviour of the appl wit and without debugger, then my first thought was the Asynch events. I moved all Asynch event logic to the In-Line events (without success). A turned off all Asynch execution of BSFNs in the Post Button Clicked event of OK and Cancel (also without success

The entry form of the appl also called via interconnect. I press from ER the Add button, which calls the Entry form and press the Cancel to return. This Find/Browse form can return without running the debugger.

I already have done this trick to enter automatically data through Press(OK) on a headerless detail form with succes. Although I did it in my custom application, not in a copied vanila OW appl.

Regards,

Zoltán

 

[peter_hamilton]

One thing to try:
1). Create a global grid variable EV01_cAutoPressOK
2). In Last record read.
set on grd_EV01_cAutoPressOK = "Y"
Insert grid row after last row
3). In row is exited async
If grd_EV01_cAutoPressOK = "Y"
Press OK
End if

Using the above, hopefully, all the grid processing has completed, and then you press the OK button.



Peter Hamilton
Xe/B9, Windows NT, AS400

 

[WhippingBoy]

OK, Zoltan. So this thing is guaranteed never to run on HTML right? If it goes to citrix you'll have to do some testing, but if this runs on the windows box you should be fine.

Ready for the 'tricky' stuff? I think this is the deal with trying to press the OK button; you can't. The initialization logic under the covers needs to finish before the tool will let you press that button. I've tried a number of tests and I can't get the thing to work with the tool either.

However, remember that the windows clients are still regular Windows programs. Very few things are impossible for a determined programmer. What you want to do is Post the WM_COMMAND that 'pressess' the OK button on the message que for the window. BUT you need to do it with a real Win API command since the tool won't do it for you.

Here's how. . . . .

The command is: PostMessage(lpBhvrCom->hDlg,WM_COMMAND,LOWORD(CONTROLID_OK),0);





Create a C business function and go through all the regular steps. If you want to press 'other' buttons you can even make a Data Structure to pass in some value. Otherwise, just pick some data structure. . .I'm sure you know how to make a C BSFN.

Put that command I typed in above into the function. . .


JDEBFRTN (ID) JDEBFWINAPI pressbutt LPBHVRCOM lpBhvrCom, LPVOID lpVoid, LPDSD98700F lpDS)
{
/************************************************************************
* Variable declarations
************************************************************************/

/************************************************************************
* Check for NULL pointers
************************************************************************/
if ((lpBhvrCom == (LPBHVRCOM) NULL) ||
(lpVoid == (LPVOID) NULL) ||
(lpDS == (LPDSD98700F) NULL))
{
jdeErrorSet (lpBhvrCom, lpVoid, (ID) 0, "4363", (LPVOID) NULL);
return ER_ERROR;
}

/************************************************************************
* Main Processing
************************************************************************/
PostMessage(lpBhvrCom->hDlg,WM_COMMAND,LOWORD(CONTROLID_OK),0);

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

return (ER_SUCCESS);
}


See?. . .cake. Anyway, test this up and down if your program isn't just running on a fat client.

Here are some other buttons you can press:

CONTROLID_OK
CONTROLID_CANCEL
CONTROLID_ADD
CONTROLID_DELETE
CONTROLID_FIND
CONTROLID_COPY
CONTROLID_CLOSE
CONTROLID_SELECT
CONTROLID_YES
CONTROLID_NO
CONTROLID_HELP
CONTROLID_TOOLS
CONTROLID_FILTER
CONTROLID_STOP

You can even press the Row and Form exit buttons, but I didn't take the time to discover how they're identified. It's by number, like the ones above, but I don't know the pattern they follow.

Let me know if this works for you.

GOOD LUCK!

 

[Zoltan_Gyimesi]

Re: RE: PressButton(HC OK) problem and Debugger

Hi Peter,

Thanks for the hint!

You won't believe, that I have already tried this trick too.

When I fill the grid from ER, then I always insert a dummy row after the last row and delete this row immediately. This action force the execution the Row Exited... events for the last inserted row.

I marked my last row and when its events finished then on the end of ER I pressed the OK. The results:

"System events stil in process"

message and controll of the appl passed to the user.

Although, I marked the last row in a EV01 based grid column, not in grid variable. Maybe I will try this again with grd variable but I don't believe really that it will work.

I will let you know, if I tried it.

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Re: RE: PressButton(HC OK) problem and Debugger

Hi Peter,

I tried with grid variables instead of grid columns in various way.

...without success

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Hi Darren,

First of all thanks for the code!

I created the C Business Function and replaced the PressButton(HC &OK) statements with calls of this BSFN.

The situation does not changed at all ((

Previously I do not describe the situation exactly.

Some OK process executed, because on the right side of the header part the Group Box and the Batch Number contol become visible and the batch number get the next batch number. This process is in the Button Clicked event of OK button.

After that happened, the user receives the control of the appl and:
- the grid rows do not added to the database, however there was neither error nor warning.
- the ER execution does not continue where the OK has been pressed.
- the form does not return



=============OMIT THIS PART - I WAS WRONG =================
THE MENTION PROCESS DOES NOT IN THE OK BUTTON CLICKED, BUT IN THE rOW EXITED ...
THE OK ASSIGN DOCUMENT NUMBER INSTEAD OF BATCH NUMBER.

EXCUSE ME THIS MISTAKE!
==========================================================
But the mentioned OK Button Clicked process is very strange!

I added a dummy control onto the form.
I assign a value and set an error for this control in the OK Button Clicked event.

The value does not appear and there is no error.

When I run the appl with debugger, the value and the error on place.
I do not understand at all.
The batch number gets the next number while my dummy control does not get the assigned value in the SAME event.

Originally I played with this dummy control on the end of the Button Clicked event of OK. I placed the set error and assinment close before the BSFN call, where the next batch number assigned. The situation does not changed.

It is very strange, isn't it?
==========================================================

Any other idea, trick?

Thanks again,

Zoltán

 

[Zoltan_Gyimesi]

PLEASE OMIT A PART OF MY PREVIOUS POST!
THE PART, WHERE I WROTE THE STRANGE OK BUTTON CLICKED.

I was wrong. The mentioned process is not in the OK but in the Row Exited &... event.

The OK assign next number to the document number instead of batch number.

I confused it.
So, the OK processing does not started at all.

Excuse me this mistake!
Today is friday and I am a bit tired and flustered.

Zoltán