Now UDFs in default value?

[CALocklin]

I tried to set a default value for character string using my own global function (UDF). It won't work. (sample app attached)

I can use A5's built-in functions and they work fine for creating a default value. However, my own functions seem to be ignored.

The UDF works just fine when tested in the interactive editor or in a script.

When I put a Debug(1) command in the UDF and try to start a new record, the UDF runs through correctly and generates the correct value but the result doesn't get entered into the field.

The only solution I could find was to put the function in the OnEnter field rule event.

I have attached a sample database. The Reg_Numbf field is the one that needs the default value.

To see that the OnEnter event works, just go to that event and unrem the command: registration_test->reg_numbf = Next_pcs_reg()

Am I missing something obvious or don't UDFs work for setting default values?

Cal Locklin
www.aimsdc.net

[G Gabriel]

RE: Now UDFs in default value?

Cal:
In the zip file you provided, the table name is "registeration_test"(obviously for the sake of the post). Your script opens "registeration_tbl". In your app, are these supposed to be one and the same table?
Comment #1: If the actual table where the field rule is "registeration_tbl", your script opens a table that is already open. This might not be a big deal, except that the script goes on to index it to a certain index for the purpose of fetch.find().
Comment #2: if the table is in entery mode, can you change the index while the table is in entery mode??
The script then runs through the records until it finds a match for base_reg.
Comment #3: base_reg needs to be DIM'd at the start of the script as global.
Don't know if any of these have any significance, but these stand out as potential problems.
Comment #4: you might want to put the first part of your script to OnActivate before the table is in entery mode.
Gabe

[csda1]

RE: Now UDFs in default value?

Cal,

You should probably be doing a refresh of the current object. Trouble is, you are using a field rule event which has no concept of the form per say. So, if you can, ascertain if a form or browse has changed/entered the field, and refresh that object on the layout.

Regards,

Ira

[CALocklin]

RE: Now UDFs in default value?

Ira, don't take this personally since you aren't the only one who has done this but why is it that every time I bring up an issue with FIELD RULES I get answers that say I should do something in the FORM EVENTS? If the field rules are there, aren't they supposed to work? Is there some reason I'm supposed to prefer adding the same event to dozens of layouts instead of just once in the field rules?

As I've already pointed out, there is no need to put this in a form event since it can be handled by putting it just once in the OnEnter event of the table.

I already have a solution to the problem as far as making the app work. The question is, "Why doesn't my UDF work to set the Default Field Value in field rules when built-in A5 functions work just fine? Am I missing something or do UDFs simply not work here?" Even a complex Default Field Value calculation like this one with 8 calls to A5 built-in function (5 functions plus repeats) that I've been using since A5v1 works fine but just one UDF won't work:
TRIM( PROJ_NUMB ) +"-"+ RIGHT( TRIM( STR( VAL( RIGHT( TRIM( DBMAX( "tasks.dbf", "proj_numb", PROJ_NUMB, "tasknumb") ), 3) ) + 1001) ), 3)

My UDF works fine in a script or in the interactive editor or in the OnEnter table event. Why doesn't it work for setting the Default Field Value? Am I the only one in the whole A5 world who has ever tried using a UDF to set a Default Field Value or did everyone else just give up?

In answer to Gabe's comments:
1. Yes, I forgot to change the table name in the function when I built the test app. (This is one reason I hate cutting down existing apps for others to test. It takes too long and it's too easy to forget something.) I'll attach a clean version. It will also add "1=1" to the OnEnter event because I got some strange errors when everything was remmed out and I tried to create a new record.
2. Since I'm opening another 'session' of the table (I'm not sure if 'session' is a completely accurate term here), I should be able to do anything I want with it. I've done this before with no problem. The DBMax() function in the example above basically does the same thing. I've also had as many as 3 different 'sessions' of the same table open simultaneously in one script. And, if it can't be done then it would be a little like saying that if one user has the table in Enter mode then nobody else can open it and change the index.
3. None of the variables in the Next_PCS_Reg() function need to be dimmed as Global since none of them are used outside the function. (Also, the Open_cnt variable was unnecessary - it was a carryover from something else and has been deleted in the new attachment.)
4. As mentioned above, I don't want to put anything in an OnActivate event or any other form event unless it's absolutely necessary. (I assume you know there is no OnActivate at the table level.) Doing things at the form level to control things that should happen whenever the table is used allows too much chance for errors because every form that can affect it must have the same event added and, even more of an issue, it's likely to be forgotten when adding a new form 6 months down the road. Heck, it wouldn't be hard to forget it the next day if you are like me and often end up working on 4-5 apps in one day. (No, not by choice but to solve problems.)

And, yes, I'm frustrated by the responses because nobody has addressed the original question that was presented: "Am I missing something obvious or don't UDFs work for setting default values?"

Cal Locklin
www.aimsdc.net

[csda1]

RE: Now UDFs in default value?

Cal,

Whoa there! All I was saying is that the UDF needs to ascertain if it's on a form or browse, and if it is, then refresh the current object. I didn't say that the UDF needed to be on a form or browse event. I'm a great believer in UDF's and their strengths. On the other hand, it is not always possible for a function to determine it's context of when and where it was executed (and clearly not in A5's or the programmer's best interest). E.g just press F8 back and forth to move between a browse and form, and you will find it real difficult to know what the parent object is and what it originally was.

My intgerpretation is that Field Rules and Layout events are happening at different levels in A5 code, and the Field Rules don't really have concept of their environment, and hence don't update the display of the object within the event without you doing it. That doesn't make it right, just is what it is.

Regards,

Ira

[G Gabriel]

RE: Now UDFs in default value?

another comment:
WHILE left( tp.Reg_numbf, 12 )
shouldn't that be:
WHILE left(Reg_numbf, 12 ) or left(tp-"Reg_numbf, 12 ) or maybe left(tp:Reg_numbf, 12 )
Gabe

[csda1]

RE: Now UDFs in default value?

Cal,

On follow up, I looked at your code in more detail. AT least as presented, it is referencing a non-existent table "registration_tbl", not "registration_test".

Other than that, it seems to work for me. Try the code below using my error handler rather than yours that goes to DONE:

Also, you don't cleanup ther error handler on the way out with an
ON ERROR GOTO 0

At the interactive, do a

dim global err as c
?err

Regards,

Ira


FUNCTION Next_PCS_reg as C ()
dim global err
err=""

DIM global open_cnt as N
open_cnt = open_cnt + 1

base_reg = "PCS-" + cdate( date() )
' ON ERROR goto Done 'error occurs when editing field rules.
ON ERROR goto Error_handler 'Ira's handler

tp = table.open( "registration_test" )
tp.index_primary_put( "Reg_numb_" )

tp.fetch_find( base_reg )

last_reg = ""
' WHILE .not. tp.fetch_eof()
WHILE left( tp.Reg_numbf, 12 ) = base_reg .and. .not. tp.fetch_eof()
last_reg = tp.Reg_numbf
tp.fetch_next()
END WHILE
tp.close()

IF last_reg = ""
Next_PCS_reg = base_reg + "-00"
ELSE
Next_PCS_reg = increment_value( last_reg )
END IF
END

Done:
END

Error_handler:
dim global err
errflag=1
errlin=error_line_number_get()
errcod=error_code_get()
errtxt=error_text_get()
err=" Line:"+LTRIM(STR(errlin)+crlf())+"Error Code:"+LTRIM(STR(errcod))+" Text:"+errtxt
ON ERROR GOTO 0
END
Resume next

END FUNCTION

[CALocklin]

RE: Now UDFs in default value?

Ira,

Ok, now I understand what you where saying but I still say it shouldn't have to be done that way AND it would certainly be a lot of work if it's even possible.

It is a default value but nobody said the cursor would ever enter that field. In that case it is going to be very difficult to refresh the "current object". Since we don't necessarily know the object name (it could be different on every layout - I hope not but it could), we could try to use something like parentform.refresh() or parentform.refresh_layout() but that really screws things up when in Enter mode.

What happens with browses? How do you refresh one field in a browse? Maybe it can be done - I just seldom use browses except for embedded browses yet I would like this to work even with the default browse.

Later - Never mind the above. I tested it with a specific form so I knew the object name and it still doesn't work. At least not when the UDF is used in the Default Field Value rule.

HOWEVER, let me re-phrase my original question....

Can anybody demonstrate a way to make a UDF work to set a default field value using the Default Field Value definition box in the Data Entry tab of the Field Rules? I don't need a work-around - I have one; I just want to know if this specific thing can be done.

Cal Locklin
www.aimsdc.net

[CALocklin]

RE: Now UDFs in default value?

Ira,

Are you sure it works FROM THE DEFAULT FIELD VALUE? Not in the interactive editor and not with the OnEnter event active - just from the Default Field Value definition.

If it does on your system, then it doesn't on mine. This is what I want to find out. Is this another of those things that seems to work on some systems but not on mine?

No shortcuts allowed:
- rem out the OnEnter event,
- put the UDF call in the Default Field Value definition (it should already be there),
- open the default browse
- start a new record in the default browse.

Now, does the default value appear in the Reg_numbf field? Today (at least for the next few minutes here in the eastern time zone) that value should be PCS-20050218-00. On my system it always comes up blank until I unrem the OnEnter event.

Cal Locklin
www.aimsdc.net

[CALocklin]

RE: Now UDFs in default value?

Just to clarify - I did try it with your version of the UDF.

[csda1]

RE: Now UDFs in default value?

Cal,

OK, I had unremed the ONEnter field rule event, not seeing the default field value and interpreting the issue as being a form vs field rule event.

Your problem (Or A5's as it was) is associated with the table reference. Take that out, and everything works OK (well at least th code and UDF left does. Make sure that you close any forms after changes to the code before trying a form again. There seems to be something different if you don't start with a fresh form load after an edit of the code. I'm not sure why. So basically, a UDF in the default field rule works. Accessing a table (maybe just the current table) seems to cause some anamoly which is what you are seeing.

So this stripped down code works;

FUNCTION Next_PCS_reg as C ()
DIM global open_cnt as N
open_cnt = open_cnt + 1

base_reg = "PCS-" + cdate( date() )
' ON ERROR goto Done 'error occurs when editing field rules.
ON ERROR goto Error_handler 'error occurs when editing field rules.

last_reg = ""

' tp = table.open( "registration_test" )
' tp.index_primary_put( "Reg_numb_" )
' tp.fetch_find( base_reg )

' WHILE left( tp.Reg_numbf, 12 ) = base_reg .and. .not. tp.fetch_eof()
' last_reg = tp.Reg_numbf
' tp.fetch_next()
' END WHILE
' tp.close()

IF last_reg = ""
Next_PCS_reg = base_reg + "-00"
ELSE
Next_PCS_reg = increment_value( last_reg )
END IF
END

Done:
END

Error_handler:
dim global err
errflag=1
errlin=error_line_number_get()
errcod=error_code_get()
errtxt=error_text_get()
err=err+crlf()+" Line:"+LTRIM(STR(errlin)+crlf())+"Error Code:"+LTRIM(STR(errcod))+" Text:"+errtxt
ON ERROR GOTO 0
END
Resume next

END FUNCTION

Uncommenting the table open and close only and the code fails. I'm sure there is a reason here, but have not identified it.

You could use an inverted index and a lookup closest to the key that would be faster and should work, in lieu of the table fetches, although I have not tested it.

Regards,

Ira

[CALocklin]

RE: Now UDFs in default value?

Thanks Ira. That got me there.

Even trying Table.Open_Session() didn't solve it but using Lookupc() did. However, that also meant adding another index based only on the first 12 characters of the registration number field - not something I wanted to do but it works.

Maybe this is something Alpha could resolve. Since the lookup also has to open the table, it must be possible.

By the way, I didn't bother with all the fancy error messages and testing because I just wanted to exit the function when the error occurred. This was only causing an error when the table was already open in exclusive mode - i.e., when I tried testing it with field rules open - however, I don't expect to be needing exclusive mode when editing the table.

Thanks,
Cal Locklin
www.aimsdc.net

[G Gabriel]

RE: Now UDFs in default value?

Cal:
I think we are missing the forest for the trees here:
UDF is a function, i.e. an EXPRESSION not just a bunch of xbasic routine. Thus, as any other function, it will receive parameters, process them and yealds a result.
In the field rule you entered NEXT_PCS_REG(). Where are the parameters that this function receives and processes?? you might say, well the parameters are base_reg + "-00". That might be true, but by simply inserting the bare function in the field rules, that does not call the xbasic and as such does not even begin to create base_reg much less assign it any value. Having the function name in the field rules does not trigger the xbasic that creates the different variables and set their values. Hence I said, this xbasic has to take place BEFORE anything else so as the parameters for the function will be known. No wonder why your "routine" works if you attach it to an event because it's more like an xbasic script as opposed to a function.
I hope you could see the difference.
A UDF will be something like this:
FUNCTION Color as C ()
Color=("red","yellow) the function's result would be: Orange
Color=("red","blue") the result: Purple
But you've got to supply the function with those parameters: In the first example Red & Yellow in the second one Red & Blue. You have not done so. You have entered a function with no parameters, the parameters of which will come after an xbasic is executed and there is nothing to trigger the execution of that xbasic.
Gabe

[csda1]

RE: Now UDFs in default value?

Hi Gabe,

Sorry, but you've got that all wrong. A UDF can not only have 0 parameters, but also can return nothing?

That doesn't make sense to you? How many parameters does DATE() have. Zero,, as it is not needed.

How many values are returned by an Init() routine? Zero. It might just intialize a bunch of global variables. This is a valid form of a function returning type V (fo Void) which has no value. It sort of defeats the basic purpose of the function concept of returning a value (and I almost always return something, even if it's just a logical true, indicating sucessful completion of the code, but that's me)

Cal's script was totally correct in this respect (one of the few people I would say has good code without even looking at it)

Regards,

Ira

[G Gabriel]

RE: Now UDFs in default value?

Ira:
""How many parameters does DATE() have.Zero""
Actually date(), time() and the like do have parameters, they are system parameters that they retrieve on their own without user's input.
Do the same rules apply to UDF?
I Don't know.
I did notice something with Cal's app though: if you create a form based on that table, insert base_reg as an object on the form for the sake of testing, close and re-open the DB, base_reg will show as an error (object refers to non existing field). On the other hand, if before you open the form, open the default browse then switch to the form, base_reg will take the proper value.
Conclusion:
1-When you open the default browse and since the the first tab field is the one with the field rule, the script runs, creates and sets the value to base_reg but somehow the chain breaks somewhere down the line
2-At least the first part of the script is correct and either something other than the script itself is getting in the way of it's completion, or there is something wrong with the script down the line
3-openeing the form did not even trigger the first part of the script that we know is correct, why?
Gabe