1. main@magicu-l.groups.io
  2. Messages
   Date   
Re: Record Flush in handler doesn't work

Steven Blank
 

Boguslaw,

'Record Flush'ACT is an Internal Event. Type Internal events cannot be raised synchronously (Wait=Yes); internal events can ONLY be raised asynchronously (Wait=No).

Events that are raised asynchronously (Wait=No) are never processed immediately; instead, they are added to the event queue where they will be processed in the future and in the same sequence in which they were queued (FIFO).

At runtime in an online task, the runtime engine only checks the event queue during its interactive phase, that is, when the runtime engine is ready to accept user input. In older parlance, the interactive phase is when task execution is within the Record Main.

Thus, events raised asychronously will only be processed during the interactive phase of task execution.

Steve Blank
Re: Record Flush in handler doesn't work

Boguslaw Uryga
 

At last I have found this working:

Event Handler:  Call ProgramB => Call Properties => Sync Data=Yes

BUT as it is said in help, it woks only in Deferred, Nested Deferred, Withi Active Transaction. For Physical transactions the option is dimmed.

Does anybody have an experience with the use of Sync Data property? Any caveats and restrictions?





2017-01-30 17:04 GMT+01:00 Florian Groothuis <f.groothuis@...>:

What I usually do is the following:

 

Event ButtonClick sets a Virtual to True and performs a RecordFlush

Event DoStuff sets that same virtual to False and is triggered by that virtual in the RecordPrefix

 

 

 

Van: main@magicu-l.groups.io [mailto:main@....io] Namens Boguslaw Uryga
Verzonden: maandag 30 januari 2017 16:06
Aan: main@magicu-l.groups.io
Onderwerp: Re: [magicu-l] Record Flush in handler doesn't work

 

Thanks Sherm,

We used that workaround for years but it is little annoying to write doubled handlers over and over again. Besides it clutters the task view and logic. 

Getting things done (and simple I would add) !


 

 

 

2017-01-30 15:29 GMT+01:00 sherman levine <slevine@...>:

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm

 

On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:

I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.

 

 

Met vriendelijke groet - With kind regards,

Florian Groothuis
Analist/programmeur
+31 (0)6 21927914


meilink.eu
Meilink Beheer Borculo B.V. • Kamerlingh Onnesstraat 1
7271 AZ  Borculo • Nederland • +31 (0)545 253525
KvK 08009803 • Our general terms and conditions apply • Disclaimer



Re: Record Flush in handler doesn't work

Florian Groothuis
 

What I usually do is the following:

 

Event ButtonClick sets a Virtual to True and performs a RecordFlush

Event DoStuff sets that same virtual to False and is triggered by that virtual in the RecordPrefix

 

 

 

Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io] Namens Boguslaw Uryga
Verzonden: maandag 30 januari 2017 16:06
Aan: main@magicu-l.groups.io
Onderwerp: Re: [magicu-l] Record Flush in handler doesn't work

 

Thanks Sherm,

We used that workaround for years but it is little annoying to write doubled handlers over and over again. Besides it clutters the task view and logic. 

Getting things done (and simple I would add) !


 

 

 

2017-01-30 15:29 GMT+01:00 sherman levine <slevine@...>:

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm

 

On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:

I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.

 

 

Met vriendelijke groet - With kind regards,

Florian Groothuis
Analist/programmeur
+31 (0)6 21927914


meilink.eu
Meilink Beheer Borculo B.V. • Kamerlingh Onnesstraat 1
7271 AZ  Borculo • Nederland • +31 (0)545 253525
KvK 08009803 • Our general terms and conditions apply • Disclaimer


Re: Record Flush in handler doesn't work

Wes Hein
 

Have you tried a Post Record Update event?

Wes 
Re: Record Flush in handler doesn't work

Boguslaw Uryga
 

Oh, sorry.  The delay method doesn't work at all. I have run another copy of test program, ha, ha.

Boguslaw.


2017-01-30 16:40 GMT+01:00 Boguslaw Uryga <b_uryga@...>:

Thanks Sherm, that's a good idea.

In the meatime I tested this in event handler:

Raise Event 'Record Flush'
Select Virtual vDelay Logical
Update vDelay with Delay(10)
Call ProgramB
Raise Event 'View Refresh'

and the changes from ProgramA show up in ProgramB and then changes from ProgramB show up in ProgramA.

This is of course not reliable in production cause the execution of Record Flush is time dependant and can or can't be expected.

Still looking for a simpler solution ......

Boguslaw.




2017-01-30 16:09 GMT+01:00 sherman levine <slevine@...>:
You can put everything into a single handler if you choose to

Handler for event EVENT

If (RunPassTwo)
    Update RunPassTwo to false
    Call program B
else
    Update RunPassTwo to True
    Record flush
    Raise event (EVENT)
EndIf






On 01/30/2017 10:05 AM, Boguslaw Uryga wrote:
Thanks Sherm,

We used that workaround for years but it is little annoying to write doubled handlers over and over again. Besides it clutters the task view and logic. 

Getting things done (and simple I would add) !




2017-01-30 15:29 GMT+01:00 sherman levine <slevine@...>:

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm


On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:
I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.
Re: Record Flush in handler doesn't work

Boguslaw Uryga
 

Thanks Sherm, that's a good idea.

In the meatime I tested this in event handler:

Raise Event 'Record Flush'
Select Virtual vDelay Logical
Update vDelay with Delay(10)
Call ProgramB
Raise Event 'View Refresh'

and the changes from ProgramA show up in ProgramB and then changes from ProgramB show up in ProgramA.

This is of course not reliable in production cause the execution of Record Flush is time dependant and can or can't be expected.

Still looking for a simpler solution ......

Boguslaw.



2017-01-30 16:09 GMT+01:00 sherman levine <slevine@...>:

You can put everything into a single handler if you choose to

Handler for event EVENT

If (RunPassTwo)
    Update RunPassTwo to false
    Call program B
else
    Update RunPassTwo to True
    Record flush
    Raise event (EVENT)
EndIf






On 01/30/2017 10:05 AM, Boguslaw Uryga wrote:
Thanks Sherm,

We used that workaround for years but it is little annoying to write doubled handlers over and over again. Besides it clutters the task view and logic. 

Getting things done (and simple I would add) !




2017-01-30 15:29 GMT+01:00 sherman levine <slevine@...>:

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm


On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:
I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.
Re: Record Flush in handler doesn't work

Boguslaw Uryga
 

Does it mean that during the handler lines execution the event queue is not interpreted ?

Boguslaw.
 

2017-01-30 15:29 GMT+01:00 sherman levine <slevine@...>:

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm


On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:
I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.
Re: Record Flush in handler doesn't work

sherman levine
 

You can put everything into a single handler if you choose to

Handler for event EVENT

If (RunPassTwo)
    Update RunPassTwo to false
    Call program B
else
    Update RunPassTwo to True
    Record flush
    Raise event (EVENT)
EndIf





On 01/30/2017 10:05 AM, Boguslaw Uryga wrote:
Thanks Sherm,

We used that workaround for years but it is little annoying to write doubled handlers over and over again. Besides it clutters the task view and logic. 

Getting things done (and simple I would add) !




2017-01-30 15:29 GMT+01:00 sherman levine <slevine@...>:

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm


On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:
I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.
Re: Record Flush in handler doesn't work

Boguslaw Uryga
 

Thanks Sherm,

We used that workaround for years but it is little annoying to write doubled handlers over and over again. Besides it clutters the task view and logic. 

Getting things done (and simple I would add) !




2017-01-30 15:29 GMT+01:00 sherman levine <slevine@...>:

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm


On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:
I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.
Re: Searching archive

Todd Baremore
 

Pavel,

Disregard, that doesn't work.   It's disappointing there is no help available on how to search.

Todd


On 1/30/2017 9:40 AM, Todd Baremore wrote:

Pavel,

Use "&" instead of "AND"

Todd


On 1/30/2017 9:09 AM, Pavel Mencl wrote:

Could you please tell me how to search  the archive here with logical AND between search terms?

Thanks

Pavel
Re: Searching archive

Todd Baremore
 

Pavel,

Use "&" instead of "AND"

Todd


On 1/30/2017 9:09 AM, Pavel Mencl wrote:

Could you please tell me how to search  the archive here with logical AND between search terms?

Thanks

Pavel
Re: Record Flush in handler doesn't work

sherman levine
 

I think the underlying issue is that the internal events are added to the processing buffer, while the call program is executed immediately.

One approach is to have the button trigger two buffered events

    Record flush (wait=no)

    User action ## (wait=no)

and have the user action handler call program B.

That will force the record flush to complete before the user action is triggered.

Sherm


On 01/30/2017 09:13 AM, Boguslaw Uryga wrote:
I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.
Record Flush in handler doesn't work

Boguslaw Uryga
 

I had an idea to simply write a record to disk before zooming to another program, to ensure that the called program sees all changes made in calling one.

I tested this in the following simple setup:

ProgramA
   - browse, allow modify, with zoom [Button]  on the form
   - handler on Event=Zoom, Ctrl=[Buttom], with two lines: Raise Event 'Record Flush'action and Call Program: ProgramB (Param=RecordID)

ProgramB (Param=RecordID)
   - screen to show the record with the passed ID

I tried different settings of Wait, Flow, Propagate options, 'Screen Refresh'act, 'View Refresh'act and even IF( stat(0,'q'mode), 'Query Records'act, 'Modify Records'act ) but it refuses to work.

Do you have any idea why doesn't it work or know any simple way to do it?   

Boguslaw.
Searching archive

Pavel Mencl
 

Could you please tell me how to search  the archive here with logical AND between search terms?

Thanks

Pavel
Re: MariaDB

voss@...
 

Hi,

as I said, Magic 10 (Express) with MariaDB (over XAMPP) without any issues.

Henning
Re: MariaDB

Manoel Frederico da Costa da Silva
 

Yes,


this web post might help you on this (translate to english):

http://blog.magicsoftware.com.br/conectando-o-magic-xpa-com-o-banco-de-dados-mariadb/


[]s
Re: MariaDB

Gijs van Ballegooijen
 

Hi,


I’m talking about the MySQL gateway for the magic xpa express license. Big chance MSE is checking for the text MySQL in some string to block access to all other kinds of databases using this crippled version of the ODBC gateway.

I don’t know for sure but would need to install a test MariaDB system to check it. So if someone already did check this, it would save me a considerable lot of time.


Kindest Regards,

Gijs van Ballegooijen.

Op 27 jan. 2017, om 08:56 heeft Rob Schapendonk <R.Schapendonk@...> het volgende geschreven:

Gijs,
 
Why should the Magic MySQL gateway not work?
 
According to Wikipedia:
“MariaDB is a community-developed fork of the MySQL relational database management system”
“MariaDB intends to maintain high compatibility with MySQL”
 
Best regards,
Rob
 
Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io] Namens Gijs van Ballegooijen
Verzonden: Thursday, January 26, 2017 15:58
Aan: main@magicu-l.groups.io
Onderwerp: [magicu-l] MariaDB
 
Hi,
 
 
Is it possible to use MariaDB with the Magic MySQL gateway?
 
 
Regards,
 
 
Gijs van Ballegooijen.
 
Re: MariaDB

Gijs van Ballegooijen
 

Hi, 

I am talking about the mysql gateway supplied with the magic xpa express edition. This is in fact an ODBC driver, but limited by MSE to be used with MySQL. 

The general ODBC driver supplied with the enterprise edition should work with MariaDB.

Maybe I have to set up a MariaDB server just to test it.


Thanks for your answer,


Gijs van Ballegooijen.
Re: Android Numeric Keyboard

Marc Gauthier
 

Thanks Joseph

its now fixed...I found out that I had a special keyboard that was overwriting the default one, the bluetooth barcode scanner (socket mobile) change the keyboard..

I will try the google keyboard to see if it fix the numeric field issue when I have decimal...


Thank You again!
Re: MariaDB

Rob Schapendonk
 

Gijs,

 

Why should the Magic MySQL gateway not work?

 

According to Wikipedia:

“MariaDB is a community-developed fork of the MySQL relational database management system”

“MariaDB intends to maintain high compatibility with MySQL”

 

Best regards,

Rob

 

Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io] Namens Gijs van Ballegooijen
Verzonden: Thursday, January 26, 2017 15:58
Aan: main@magicu-l.groups.io
Onderwerp: [magicu-l] MariaDB

 

Hi,

 

 

Is it possible to use MariaDB with the Magic MySQL gateway?

 

 

Regards,

 

 

Gijs van Ballegooijen.

 
12281 - 12300 of 195966