Need help in some codes

[Dave Reyes]

Hi. Newbie programmer here.
I was assigned to create an electronic raffle program.
I created a table where all the entries that can be drawn by the program are saved there.
I also created a field where whenever the program draws the entry, it will be marked and will not be able to be drawn again (more like of a checker of yes/no).
My problem is, whether the entry is marked or not, it is still being drawn by the program.

I used the RANDOM statement for randomization/picking of the ticket number.

All help would be appreciated. Thanks and God Bless.

 

[TomBascom]

A wise man once said "God does not play dice".

Among other things you want to be using the -rand2 startup parameter. It would be more sensible for this use case.

You will need to show your code for a more detailed answer about why things are being drawn when you don't want them to be.

 

[Dave Reyes]

Soory about that.
Here's a sample of my code:

ASSIGN fiWinner.
     FOR EACH Names.
         iLastNum = iLastNum + 1.
     END.
 
    IF btnDraw:LABEL = "Draw" THEN DO:   
        iRandom = STRING(RANDOM(1,iLastNum)).
        FIND FIRST Names WHERE TixNum = iRandom AND Checker = NO.
        IF AVAIL Names THEN DO:
            fiWinner = Names.RaffleName.
            DISPLAY fiWinner WITH FRAME {&FRAME-NAME}.
            UPDATE Names.Checker = YES.
        END.
        ELSE IF NOT AVAIL Names THEN DO:
            FIND NEXT Names WHERE Checker = NO.
            fiWinner = Names.RaffleName.
            DISPLAY fiWinner WITH FRAME {&FRAME-NAME}.
            UPDATE Names.Checker = YES.
        END.
        pTimer:SENSITIVE = FALSE.
        btnDraw:LABEL = "Reset".
        RETURN.
    END.
 
    IF btnDraw:LABEL = "Reset" THEN DO:
        HIDE fiWinner IN FRAME {&FRAME-NAME}.
        pTimer:SENSITIVE = TRUE.
        btnDraw:LABEL = "Draw".
        RETURN.
    END.

 

[TomBascom]

Right off the bat you have some very serious transaction, record and lock scoping issues. Without a more complete context it is difficult to say how serious that it. But you should *always* specify your lock type and you should *always* explicitly declare your transaction blocks.

I'm not sure what you think that first line is doing.

What is fiWinner?

iLastNum is not initialized before counting -- if this code is a trigger and iLastNum is declared outside of it the second invocation will add on to the first.

Is there supposed to be any sort of correspondence between iLastNum as TixNum? If there is then the comment above is even more critical. If there is not then your drawing methodology using random( 1, iLastNum) doesn't make much sense.

Surprisingly, "UPDATE Names.Checker = YES." is legal but most Progress people wouldn't expect it to be. I'm not sure it is doing what you think it should do. Usually an assignment would be either "ASSIGN Names.Checker = YES." or, more simply, "Names.Checker = YES." UPDATE is generally used when prompting for input.

You're using FIND FIRST -- why? Is TixNum not unique?

What happens if your FIND NEXT fails? (You do not seem to be handling that possibility.)

I don't know anything about how the pTimer widget works -- but it looks spurious to this code. Why would you need any sort of "timer" for this? What happens when it fires?

 

[GregTomkins]

How can I compete with an answer like that?

IMO you should avoid basing logic on the value of 'LABEL', IMHO. It makes it vulnerable to breaking when someone makes a minor wording change (eg. Reset -> Restart).

Also, it will break if you have to internationalize, though I realize most of you live in a country where you don't have to worry about that possibility

 

[Cringer]

Right off the bat you have some very serious transaction, record and lock scoping issues. Without a more complete context it is difficult to say how serious that it. But you should *always* specify your lock type and you should *always* explicitly declare your transaction blocks.

The only exception being if Names is actually a temp-table.

 

[TomBascom]

In that case there are no locks associated with the TT -- but you could still have a transaction if it is an UNDO TT. And buffer scope remains important.

 

[Dave Reyes]

Sorry about the first line, I actually erased that already.
This code is for a CHOOSE trigger of btnDraw.
iLastNum is an integer that I declared to get the total number of entries in the table Names.
TixNum(or Ticket Number) is the table field which has a corresponding name that will appear on the screen once an equivalent value of the TixNum is randomed.
I actually have no other contingency when the FIND NEXT fails.
That's why I posted to ask opinions.