New feature suggestion : Fields with entry if and proceduresdesignerID

[Deskin, Bob]

How often are these conditions shared in both Entry and Find mode? Remember that the generated DESIGNER procedures are used both in Correct and Change.
 
Bob

	-----Original Message-----
	From: Ken Langendock [mailto:Ken at Langendock.com] 
	Sent: July 24, 2007 12:08 PM
	To: Deskin, Bob; 'Daniel Rodríguez'; powerh-l at lists.sowder.com
	Subject: RE: New feature suggestion : Fields with entry if and proceduresdesignerID
	
	
	Bob, I understand your position. Break existing code is a bad thing...
	 
	I would LOVE an option in the Dictionary or on the Qdesign statement that would generate numbered procedures with or without the IF options.
	 
	Interdependencies may be a problem for some, but having to write number designer procedures to simulate the same sequence as the entry procedure is of a real pain to me.
	 
	Ken
	
________________________________

	From: powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com [mailto:powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com] On Behalf Of Deskin, Bob
	Sent: July 24, 2007 11:55 AM
	To: Daniel Rodríguez; powerh-l at lists.sowder.com
	Subject: RE: New feature suggestion : Fields with entry if and proceduresdesignerID
	
	
	The ENTRY IF generates the IF condition around the ACCEPT for the field in the ENTRY procedure. The ENTRY procedure is generated and processed in a linear manner. In other words, one field after another in the same sequence as the fields appear on the screen. If the condition is dependant on another field, it's quite easy for the developer to know whether that field has been entered or not.
	 
	Numbered DESIGNER procedures, on the other hand, can be executed out of sequence. You can easily change fields in a different sequence than the entry sequence. Inter-field dependencies can't be counted on in the same way as they can during entry. This means that simply generating the IF condition in a DESIGNER procedure might be more confusing.
	 
	For inter-field issues, you can handle them in the PREUPDATE procedure, where all inter-field relationships can be verified. The alternative is to create numbered DESIGNER procedures for the fields in question and have the DESIGNER procedures prompt for all of the inter-related fields. While this could be generated if the fields are linked by the same ID, often the fields are not related by ID.
	 
	Now I realize that you can argue this one both ways and that there are many cases where simple conditions would work fine. However, once the decision was made and a few years went by, any change would have potentially affected many applications, so no change could be made.
	 
	Bob
	 

		-----Original Message-----
		From: powerh-l-bounces+bob.deskin=cognos.com at lists.sowder.com [mailto:powerh-l-bounces+bob.deskin=cognos.com at lists.sowder.com] On Behalf Of Daniel Rodríguez
		Sent: July 24, 2007 11:34 AM
		To: powerh-l at lists.sowder.com
		Subject: New feature suggestion : Fields with entry if and procedures designerID
		
		
		When you create a screen with fields with the ENTRY IF option, you must write a procedure designer for the ID number in order to obtain the same behavior in change mode than in entry mode.
		
		Is there any special reason for it or I'm missing something? 
		
		It is possible that Qdesign autogenerate the code if the procedure doesn't already exists?
		
		Kind regards,
		
		Daniel Rodriguez
		
		
		SCREEN PRUEBA
		
		TEMP TFIELD1 CHAR*2
		TEMP TFIELD2 CHAR*2 
		
		FIELD TFIELD1
		FIELD TFIELD2 ENTRY IF TFIELD1 = "XX"
		
		PROCEDURE DESIGNER 02
		BEGIN
		 IF TFIELD1 = "XX"
		 THEN
		  ACCEPT TFIELD2 
		END 
		
		
		

	 
	     This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20070724/5c212bab/attachment-0001.htm