Page Index Toggle Pages: 1 [2]  Send Topic Send Topic Print Print
Hot Topic (More than 10 Replies) On Form Change Programming (Read 4427 times)
SpencerWulwick
Senior Member
Members
*****
Offline



Posts: 677
Location: Wilton Manors, Florida
Joined: Jan 16th, 2005
Re: On Form Change Programming
Reply #15 - Mar 4th, 2005 at 11:11pm
Print Post Print Post  
Bob -

THANK YOU!!!!

That makes me feel better, actually.  I would hate to see programming that isn't necessary when there is something better. 

So, we haven't really made an "exception" to the rule ... we simply "modified" the rule.  lol

Seriously, it's good to know that it does, indeed, serve a useful purpose and I'm glad to know the distinction.

Besides the "fun" I'm having with Sesame, it's also nice to be in touch with you again.

Sesame is driving me crazy though.  I was just thinking ... I'm leaving my computer - I've got to eat.  And I just remembered that I didn't change my "age calculation" programming which I MUST do RIGHT NOW.  Will I ever recognize my "life" again?   lol
  

- Spencer

    ** Practice random kindness & senseless acts of beauty!
Back to top
IP Logged
 
Hammer
YaBB Administrator
Lanticans
*****
Offline


Fire bad. Tree pretty.

Posts: 3436
Location: Ohio
Joined: Nov 22nd, 2002
Re: On Form Change Programming
Reply #16 - Mar 5th, 2005 at 1:39pm
Print Post Print Post  
Quote:
For every rule there is an exception Spencer:
Don't always use @IsBlank. 

That only works for Layout Elements.

Still need to use <>"" for variables.
---------------------------------
From the supplement documentation, page 22:

@IsBlank(element)
Type: Miscellaneous
Parameters:Layout Element as ElementRef
Returns: Boolean


Bob is correct. However, just to elaborate on what he says above...

You need to test your variables in a way appropriate to their type.
String
If vMyVar <> ""

Int or Double
If vMyVar > 0

... and so on.

As with LEs, testing a numeric variable by comparing it to "" may have unexpected results.
  

- Hammer
The plural of anecdote is not data.
Back to top
IP Logged
 
SpencerWulwick
Senior Member
Members
*****
Offline



Posts: 677
Location: Wilton Manors, Florida
Joined: Jan 16th, 2005
Re: On Form Change Programming
Reply #17 - Mar 10th, 2005 at 11:39pm
Print Post Print Post  
Ray -

I hope you see this because I am somewhat confused regarding the programming to calculate age, based on date of birth.  Earlier I indicated that I was using the following code:

Code
Select All
if Birthdate <> ""

 Age = @year(@date)-@year(Birthdate)-((@month(@date)<@month(Birthdate))
 or (@month (@date) = @month(Birthdate) and @dom(@date)<@dom(Birthdate)))
  



You said:

Quote:
The "or (@month (@date) = @month(Birthdate) and @dom(@date)<@dom(Birthdate))) " line in your code isn't going to do anything. 


On looking at the code, I thought that you might be right because I didn't see any conditions applied such as 'then/else'.

You recommended the following code (which to me looked right):

Code
Select All
If Not @IsBlank(BirthDate) Then
{
     If (@Month(BirthDate) < @Month(@Date)) Or ((@Month(BirthDate) = @Month(@Date)) And (@DOM(BirthDate) <= @DOM(@Date)))

     Then  {   Age = @Year(@Date) - @Year(BirthDate) + 1  }    Else  {   Age = @Year(@Date) - @Year(BirthDate)  } }    



So, I tried it and it made me a year older.  I tried every possible variation of the code I could think of (taking into account the month and day, as well of the year) and, for the life of me, I could not get it to come out right.

So, I went back to this:
Code
Select All
If not @isblank(Birthdate) then
     Age = @YEAR(@DATE)-@YEAR(BirthDate) - ((@MONTH(@DATE) < @MONTH(BirthDate))
     or (@MONTH(@DATE) = @MONTH(BirthDate) AND @DOM(@DATE) < @DOM(BirthDate))) 



I tried it and my age was back to what it should be.  I then tested every possible scenario.  On March 10, 2005, for example, a birthdate of March 10 2003 (or earlier) reports the age as 2.  A birthdate of March 11, 2004 (or later) reports the age as 1. 

I even played with leap year scenarios (including changing my computer clock to February 29th 2004) and everything seemed to check out appropriately.

I am just wondering whether the way the code is constructed, there is an 'implied' if/then/esle condition because, as I said, it appears to work flawlessly.  If the 'or" portion of the code did not work, then I would think I would not get accurate results right down to the actual birthday.

Any thoughts about this? ... as I'm always trying to learn more about and better understand any code that I use.

Thanks!
  

- Spencer

    ** Practice random kindness & senseless acts of beauty!
Back to top
IP Logged
 
Hammer
YaBB Administrator
Lanticans
*****
Offline


Fire bad. Tree pretty.

Posts: 3436
Location: Ohio
Joined: Nov 22nd, 2002
Re: On Form Change Programming
Reply #18 - Mar 11th, 2005 at 12:54am
Print Post Print Post  
Spencer,

You original code works because it's doing something tricky. The problem is that, because it's tricky, it's also difficult to understand and maintain.  I'll resolve it for you step-by step so you can see how it works.

Assume that Birthdate = Feb 12, 1969

You start with this:
Age = @YEAR(@DATE) - @YEAR(BirthDate) - ((@MONTH(@DATE) < @MONTH(BirthDate)) or (@MONTH(@DATE) = @MONTH(BirthDate) AND @DOM(@DATE) < @DOM(BirthDate)))

If we resolve all the @Year, @Month, etc., we end up with this:
Age = 2005 - 1969 - ((3 < 2) or (3 = 2 AND 10 < 12))

Here's where the trick comes in. Each of the boolean expressions below (like 3 < 2) resolves to True (1) or False (0). Since 3 < 2, the first expression below resolves to False or 0. The whole things resolves as follows:
Age = 2005 - 1969 - ((0) or (0 AND 1))

The last expression is (0 AND 1). For an expression like this which uses AND to be True, all it's parts must be True. In this case, one of the parts is False (0), so the whole thing resolves to 0.
Age = 2005 - 1969 - ((0) or (0))

The last remaining expression uses OR. If any of the parts are True, the whole thing is True. In this case, both parts are False, so the whole things resolves to 0.
Age = 2005 - 1969 - 0

Now, you have resolved all the expressions except the final subtraction. Notice that the final number is 0. If any of the bits above had been True, the last number would have been 1.
Age = 36

That's how the trick works.

The method Ray used is less slick, but it's also more obvious and easier to read. In specific, however, there is a  condition reversed, so you're getting funny results. Give this a try:
Code
Select All
If Not @IsBlank(BirthDate) Then
{
	If (@Month(BirthDate) < @Month(@Date)) Or ((@Month(BirthDate) = @Month(@Date)) And (@DOM(BirthDate) <= @DOM(@Date)))
	{
		Age = @Year(@Date) - @Year(BirthDate)
	}
	Else
	{
		Age = @Year(@Date) - @Year(BirthDate) - 1
	}
}
 



Or this:
Code
Select All
var vOffset as Int

vOffset = 0
If Not @IsBlank(BirthDate) Then
{
	If (@Month(@Date) < @Month(BirthDate)) Or ((@Month(@Date) = @Month(BirthDate)) And (@DOM(@Date) < @DOM(BirthDate)))
	  {
		   vOffset = 1
	  }
	Age = @Year(@Date) - @Year(BirthDate) - vOffset
}
 


  

- Hammer
The plural of anecdote is not data.
Back to top
IP Logged
 
Page Index Toggle Pages: 1 [2] 
Send Topic Send Topic Print Print