Answered Using song effect for user action

Hi everyone,

I have a programm that's playing song if the transaction was successful and another if it wasn't. We are using them to help the operator notice that something is wrong.
But the first time it's used, it's really low to come. Do you have already done this ? how? What are your advices?

Best-Regards,

- BobyIsProgress -
 

Cringer

ProgressTalk.com Moderator
Staff member
Is your question that the sound file takes a while to load and play?
Some code would no doubt help to understand, but I'm guessing the file is stored on a server somewhere and needs to be downloaded locally to be used.
 
Hi,

there is the code:

Code:
DEFINE INPUT PARAMETER cson AS CHARACTER    NO-UNDO.

DEFINE VARIABLE ReturnValue AS INTEGER      NO-UNDO.
DEFINE VARIABLE szSound     AS MEMPTR       NO-UNDO.

&GLOB SND_ASYNC 1
&GLOB SND_NODEFAULT 2
&GLOB SND_LOOP 8
&GLOB SND_PURGE 64
&GLOB SND_APPLICATION 128
&GLOB SND_ALIAS 65536
&GLOB SND_FILENAME 131072
&GLOB SND_RESOURCE 262148

PROCEDURE PlaySoundA EXTERNAL "winmm.dll" PERSISTENT :
  DEFINE INPUT PARAMETER  pszSound    AS LONG.
  DEFINE INPUT PARAMETER  hmod        AS LONG.
  DEFINE INPUT PARAMETER  fdwSound    AS LONG.
  DEFINE RETURN PARAMETER ReturnValue AS LONG.
END PROCEDURE.
            
FIND FIRST SPAZPL WHERE SPAZPL.zpacod    = "SON"
                  AND   SPAZPL.zpavalcod = cson NO-LOCK NO-ERROR .
IF AVAILABLE SPAZPL THEN
    cson = SEARCH(SPAZPL.zpavallib) .

IF cson <> ? THEN DO :
    SET-SIZE(szSound) = LENGTH(cson, "raw":U) + 1.
    PUT-STRING(szSound,1) = cson.

    RUN PlaySoundA (GET-POINTER-VALUE(szSound),
                    0,
                    {&SND_FILENAME},
                    OUTPUT ReturnValue).
    SET-SIZE(szSound) = 0.
END.

RETURN NO-APPLY .
 

Cringer

ProgressTalk.com Moderator
Staff member
It would be interesting to have some profiling on that code to see where the delay occurs.
 

TomBascom

Curmudgeon
The FIND FIRST looks bogus.

If the PROPATH is long, or contains slow network drives, that could be an issue but I'm guessing that the main problem is that the PUT-STRING() is loading it from a network drive.

Profiling would be interesting. A few log messages detailing what is being loaded, from where, and how big it actually is would also be interesting.
 
Hi,

All the song are local to the machine. They are in the work folder on every computer using progress.
The main song we are using (the one in "cson = SEARCH(SPAZPL.zpavallib)" ) weight around 51Ko.

PROPATH/wav/ok.wav

Code:
DEFINE INPUT PARAMETER cson AS CHARACTER    NO-UNDO.

DEFINE VARIABLE ReturnValue AS INTEGER      NO-UNDO.
DEFINE VARIABLE szSound     AS MEMPTR       NO-UNDO.

&GLOB SND_ASYNC 1
&GLOB SND_NODEFAULT 2
&GLOB SND_LOOP 8
&GLOB SND_PURGE 64
&GLOB SND_APPLICATION 128
&GLOB SND_ALIAS 65536
&GLOB SND_FILENAME 131072
&GLOB SND_RESOURCE 262148

PROCEDURE PlaySoundA EXTERNAL "winmm.dll" PERSISTENT :
  DEFINE INPUT PARAMETER  pszSound    AS LONG.
  DEFINE INPUT PARAMETER  hmod        AS LONG.
  DEFINE INPUT PARAMETER  fdwSound    AS LONG.
  DEFINE RETURN PARAMETER ReturnValue AS LONG.
END PROCEDURE.
            
FIND FIRST SPAZPL WHERE SPAZPL.zpacod    = "SON"
                  AND   SPAZPL.zpavalcod = cson NO-LOCK NO-ERROR .
IF AVAILABLE SPAZPL THEN
    cson = SEARCH(SPAZPL.zpavallib) . /* wav/ok.wav 50Ko */

IF cson <> ? THEN DO :
    SET-SIZE(szSound) = LENGTH(cson, "raw":U) + 1.
    PUT-STRING(szSound,1) = cson.

    RUN PlaySoundA (GET-POINTER-VALUE(szSound), /* procedure in the dll load before */
                    0,
                    {&SND_FILENAME},
                    OUTPUT ReturnValue).
    SET-SIZE(szSound) = 0.
END.

RETURN NO-APPLY .
 

TomBascom

Curmudgeon
That PROPATH is obviously a fantasy. That is not the actual value. Please show the actual PROPATH by adding:

Code:
message propath.

to your code and logging it.

Please log the actual values of the other items requested as well.

There is often a difference between what you imagine your code is doing and what it is actually doing. Those differences are frequently the source of problems such as those that you are asking for our help to resolve. If you are not going to accurately report what is actually happening and if you are going to pick and chose which follow-up questions to respond to then you can expect no further help.
 

Cecil

19+ years progress programming and still learning.
Have you tried using .NET? I got this to work with in a few minuets.

Code:
USING System.Media.*.

DEFINE VARIABLE player AS CLASS SoundPlayer.

player = NEW SoundPlayer().
player:SoundLocation = "C:\Windows\media\Alarm02.wav".
player:Play().

FINALLY:

    IF VALID-OBJECT(player) THEN
        DELETE OBJECT player.

END.
 
Last edited:

Cecil

19+ years progress programming and still learning.
Also, I have never been a fan of the SEARCH() method. Try using:

Code:
FILE-INFO:FILE-NAME = SPAZPL.zpavallib.

cson = FILE-INFO:FULL-PATHNAME.

IF cson NE ? THEN
DO:
    player:SoundLocation = cson.
    player:Play().
END.
 
Last edited:
Also, I have never been a fan of the SEARCH() method. Try using:

Code:
FILE-INFO:FILE-NAME = SPAZPL.zpavallib.

cson = FILE-INFO:FULL-PATHNAME.

IF cson NE ? THEN
DO:
    player:SoundLocation = cson.
    player:Play().
END.

Thank You @Cecil .

Can you explain why ? Not that I don't believe you, but to know what are you tought about the two methods :) .

Best Regards,

- BobyIsProgress -
 

TomBascom

Curmudgeon
Complicated PROPATHs are a bad idea regardless. Putting a network drive on the PROPATH is an even worse idea.

Both SEARCH and FILE-INFO will follow the PROPATH for relative file names.

SEARCH knows how to find things inside a PROLIB, FILE-INFO does not.

When FILE-INFO finds something it also populates useful attributes like the size, creation and modification timestamps.

Unless you are wanting to find something that might live in a PROLIB, FILE-INFO is usually going to be more useful.
 

Cecil

19+ years progress programming and still learning.
Complicated PROPATHs are a bad idea regardless. Putting a network drive on the PROPATH is an even worse idea.

Both SEARCH and FILE-INFO will follow the PROPATH for relative file names.

SEARCH knows how to find things inside a PROLIB, FILE-INFO does not.

When FILE-INFO finds something it also populates useful attributes like the size, creation and modification timestamps.

Unless you are wanting to find something that might live in a PROLIB, FILE-INFO is usually going to be more useful.

This basically sums it up. This is what I was going to say in a nutshell.
 
Last edited:
So for info I just put the new sound solution to prod this morning with the FILE-INFO and it works perfectly way. I have no 0 delay :)

Thank you everyone :)
 
Hi,

So I encounter an issue now that I haven't anticipated. If the computer that is using it, don't have the right framework the application shut down right away. Do you have a way to detect it or is it unpossible.

Best Regards,

BobyIsProgress
 

Osborne

Active Member
I don't know if these are any help but 2 possible options:

Option 1:
Code:
DEFINE VARIABLE cRelease AS CHARACTER NO-UNDO.
DEFINE VARIABLE cVersion AS CHARACTER NO-UNDO.

LOAD "SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full".
USE "SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full".
GET-KEY-VALUE SECTION "1033" KEY "Release" VALUE cRelease.
GET-KEY-VALUE SECTION "1033" KEY "Version" VALUE cVersion.
UNLOAD "SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full".

MESSAGE "Release =" cRelease SKIP
        "Version =" cVersion
        VIEW-AS ALERT-BOX.

Option 2:
Code:
DEFINE VARIABLE oAssembly AS System.Reflection.Assembly NO-UNDO.

oAssembly = System.Reflection.Assembly:LoadFile("C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.dll").
MESSAGE oAssembly:FullName VIEW-AS ALERT-BOX.
 
Last edited:
Top