Description: ------------ Version 1.3.2 fixes the previous PHP Notice in the PDF converter but adds a new one. Notice: Trying to get property of non-object in /usr/share/php/PhpDocumentor/phpDocumentor/Converters/PDF/default/PDFdefaultConverter.inc on line 210 Line 186 is: if (!$element) return false; But should really be... if (!$element && !is_object($element)) return false; Also the docs for this function are wrong.

Wow.. Logic error in my head... if(!$element || !is_object($element)) return false;

cardoe, I am not able to duplicate that PDF error pointing at line 210, so I'm not able to reliably test your patch idea. Any chance you can post a small docblock that you can trigger it with?

I was, however, able to generate a PHP Notice from the PDF default converter pointing at line 533, where it complained about code that tried to default a function's return type when no return tag was in the docblock. I've attached the patch for that problem, though I still think Doug's original problem relates to another issue that I want to tackle if I can.

I made the following tweak to spit out some more details.. if (!$element) return false; if (!is_object($element)) var_dump($element); Which results in the following being printed.. string(12) "object array" Notice: Trying to get property of non-object in /usr/share/php/PhpDocumentor/phpDocumentor/Converters/PDF/default/PDFdefaultConverter.inc on line 213 I'm running this on a whole bunch of files so I'm not sure which docblock this is coming from... My only guess is at the very start of a file I have the following block: @package MyCompany @subpackage @see Class1, Class2, Class3, Class4 @see Class5, Class6, Class7, Class8 @see Class9 for the file level docblock.

Should be noted that the Notice is only printed 9 times and there are 9 classes referenced in that file level docblock.

That subpackage tag is empty? Also, are the files containing those nine class definitions also included in your run?

erm. No That was just a typo on my part with the @subpackage, it has stuff in it. Currently our structure is: MyCompany/subpackage/PossibleError.php MyCompany/subpackage/Class1.php MyCompany/subpackage/Class2.php MyCompany/subpackage/Class3.php MyCompany/subpackage/Class4.php MyCompany/subpackage/Class5.php MyCompany/subpackage/Class6.php MyCompany/subpackage/Class7.php MyCompany/subpackage/Class8.php MyCompany/subpackage/Class9.php Where PossibleError.php contains the file level doc block I previously posted. All the classes are in the same subpackage. I've actually been working here internally to publish this code since it's designed to be a PEAR pkg for interfacing to my company's software. Hopefully I can give specific files as reference soon.

Do the class-level docblocks also have the same package and subpackage tags on them?

Yes. There's actually a file level doc block. Then some includes, which has it's own doc block since I was getting warnings without that. Then the class level doc block. The file level and class level doc blocks have the same @package and @subpackage sections. The include level one does not.

Does removing the @see tags stop the notices from happening?

I should have checked that before... sorry.. I've removed all @see from my sources and I still get it. This is in a SVN checkout however, so there still are pristine copies with @see in them, but I assume you don't parse anything that doesn't end in .php

I've added a debug_print_backtrace() in there... #0 PDFdefaultConverter->returnSee(object array, array, 1) called at [/usr/share/php/PhpDocumentor/phpDocumentor/ParserElements.inc:647] #1 parserFunction->getIntricateFunctionCall(PDFdefaultConverter Object ([sort_absolutely_everything] => 1,[leftindex] => Array ([classes] => ,[pages] = > ,[functions] => ,[defines] => ,[globals] => ),[pagepackage_pagenums] => Array (),[classpackage_pagenums] => Array (),[outputformat] => PDF,[name] => d efault,[curpagepackage] => Monetra,[curclasspackage] => Monetra,[smarty_dir] => /usr/share/php/data/PhpDocumentor/phpDocumentor/Converters/PDF/default/t emplates/default/,[pdf] => phpdocpdf Object ([reportContents] => Array (),[indexContents] => Array (),[indents] => Array (),[font_dir] => /usr/share/php /data/PhpDocumentor/phpDocumentor/Converters/PDF/default/templates/fonts/,[set_pageNumbering] => ,[converter] => PDFdefaultConverter Object ( *RECURSION * After the RECURSION.. it goes on and on for several hundreds of lines.. I can't quite catch the other calls but here's the end.. #8 phpDocumentor_IntermediateParser->Output() called at [/usr/share/php/PhpDocumentor/phpDocumentor/Setup.inc.php:674] #9 phpDocumentor_setup->createDocs() called at [/usr/share/php/PhpDocumentor/phpDocumentor/phpdoc.inc:61] #10 include(/usr/share/php/PhpDocumentor/phpDocumentor/phpdoc.inc) called at [/usr/bin/phpdoc:37]

Guess I could just write my own to filter out the args from debug_backtrace(). PDFdefaultConverter->returnSee() called at [/usr/share/php/PhpDocumentor/phpDocumentor/ParserElements.inc:647] parserFunction->getIntricateFunctionCall() called at [/usr/share/php/PhpDocumentor/phpDocumentor/ParserElements.inc:1680] parserMethod->getIntricateFunctionCall() called at [/usr/share/php/PhpDocumentor/phpDocumentor/Converters/PDF/default/PDFdefaultConverter.inc:420] PDFdefaultConverter->convertMethod() called at [/usr/share/php/PhpDocumentor/phpDocumentor/Converter.inc:3969] Converter->Convert() called at [/usr/share/php/PhpDocumentor/phpDocumentor/Converter.inc:2380] Converter->walk_everything() called at [/usr/share/php/PhpDocumentor/phpDocumentor/Converter.inc:1842] Converter->walk() called at [/usr/share/php/PhpDocumentor/phpDocumentor/IntermediateParser.inc:1627] phpDocumentor_IntermediateParser->Convert() called at [/usr/share/php/PhpDocumentor/phpDocumentor/IntermediateParser.inc:1840] phpDocumentor_IntermediateParser->Output() called at [/usr/share/php/PhpDocumentor/phpDocumentor/Setup.inc.php:674] phpDocumentor_setup->createDocs() called at [/usr/share/php/PhpDocumentor/phpDocumentor/phpdoc.inc:61] include() called at [/usr/bin/phpdoc:37]

Just before the returnSee call on /usr/share/php/PhpDocumentor/phpDocumentor/ParserElements.inc:647 I added print_r($link) and got: classLink Object ( [type] => class [path] => /usr/local/php/MyCompany/MyComapny.php [fileAlias] => MyCompany---MyCompany.php [name] => MyCompany [category] => default [package] => MyCompany [subpackage] => ) That file does not have a @subpackage. It appears to be correct.. I added an exit; to returnSee() when it got a non-object and that's the only thing that prints out.

Actually.. my mistake... Adding the following code before line 647... echo $param[2] . " param2\n"; var_dump($link); echo "\nprint_r" . "\n"; Produces: array param2 string(12) "object array" print_r I do use "array" to decorate some of my parameters in my code since some of them are raw arrays. You're allowed in PHP 5 to decorate your parameters with their class name or the parameter "array". Changing line 643 from: if (isset($param[2])) to: if (isset($param[2]) && $param[2] != "array") Fixes the issue as well.

Any word on this? Need me to do anymore testing? Once you push out 1.4.0a2, I'll probably switch to that version to test.

I've still not been able to duplicate Doug's specific PHP notice error. My testing against the @return code, that I COULD trigger the notices with, continues to be good. I'm going to commit that fix, and continue working with Doug to try duplicating his scenario.

committed @return patch

Doug, Although I can't imagine my @return patch solving your issue, can you at least patch your file so that you and I are testing against the same PDFdefaultConverter.inc file? I still cannot put together a test file / tags combination to trigger the notices you're getting around the 210 line, so I need some more "hints" regarding your code that you can't show just yet.

this is a test comment by Chuck

Nothing further on this since committing my @return patch, so closing this bug.