It is always frustrating to spend days tracking down a bug and finding out that it is a fundamental 4D bug. I spent a week earlier this year tracking down a significant bug with OB SET that was as reported with v16 R2 but as far as I can tell has not been fixed (ACI0096772).
Now a significant bug with OBJECT SET SUBFORM. A bug report has been made to 4D but I wanted to post it on the iNUG so that others could be warned. A subform object with the correct name is verified to exist. The following code shows that OBJECT SET SUBFORM does not work. OBJECT SET SUBFORM(*;"ob_EventInput_Doc_Subform";[Documents];"Documents_Subform") OBJECT GET SUBFORM(*;"ob_EventInput_Doc_Subform";$ptr_SubformTable;$t_SubFormDetailName;$t_SubFormListName) ASSERT($t_SubFormDetailName="Documents_Subform") and the ASSERT always fails. ptr_SubformTable is Nil and t_SubFormListName is "" This is being executed with the page of the form with the subform already selected as the current page. This fails with all variations of the Subform object properties: source, Detail form, Automatic Width, and Output Subform. The documentation in the Language Reference and Design Reference do not specify any conditions under which this should fail. There is nothing in the Knowledgebase addressing this problem. The only work-around is to use forms with hard-coded subform tables and names. Regards, Leonard Soloniuk, MD ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
