[TYPO3-project-formidable] New Revision 162

[Jerome Schneider]

Hi Manuel, René,

Thanks to your indications, I corrected this behaviour in rev 163.

The problem was that forceEntryId has to be considered only if the given 
uid is different of the currently edited uid

And this, because forceEntryId will tell formidable not to save data in 
DB even if values have been submitted, as if it's forced, it is 
supposedly because de forced uid is different of the current one.

And that's also the reason why, at line 635 (now line 639 in new 
revision) of maindatahandler, we use the method
	
	getRdtValue_noSubmit_edit()

even if there is submitted data available.

Not sure if I'm clear, but if not just let me know.
See also commentary in modified sections of code for better 
understanding of what's going on.


Thanks for your help,
Jerome

Manuel Rego Casasnovas a écrit :
> Hello Jerome,
> 
> what about this e-mail:
> http://lists.netfielders.de/pipermail/typo3-project-formidable/2008-January/000833.html
> 
> ReneŽ and me have problems with the new releases, and we think that the
> problem could be the comparison at line 643 of
> class.maindatahandler.php:
> 
> if($this->oForm->iForcedEntryId !== FALSE) {
> 
> 	return $this->getRdtValue_noSubmit_edit($sName);
> }
> 
> 
> Maybe a possible solution would be:
> 
> ($this->oForm->iForcedEntryId === TRUE)
> 
> 
> I'm using this solution ant it seems that work.
> 
> 
> Best regards,
> Rego
> 
> 
> PS: Thanks to adopt my patches ;-)
> 
>