@@: LJ Longwing,
That sounds like it may probably be the reason why they may have not included $FIELDHELP$ (good reverse analysis..) - except that the help cumulatively does get loaded and can be seen if you press the Help toolbar if made available on the Mid-Tier on the form (see Fredrick's related email) Hypothetically assuming you are right on the reason, I think they should implement it anyway, and leave it to the developer to decide if he wants to or not have help associated with his objects. Let the developer worry about its impact to the system as afar as performance is concerned. Let it be known that the more help you have associated with your fields and your forms, the thicker they get and the bigger your network packets would get. @@: Fredrick Grooms Yes I did notice that the Help on the toolbar does load ALL the help defined on all the fields of the form. So that makes you wonder why wasn't it available for $FIELDHELP$ if the Help was available in that generic way. @@: Natlalie I concur completely. Not making a feature available altogether for performance reasons (IF that is the reason why it was not made available) sound unreasonable. Again I know LJ is only sporting a guess (a good one at that), its like implementing a hard limit to number of searches you can develop in set field if or push field if actions because searches if implemented badly could be a dangerous thing too.. But then how useful would a system be if such a limitation were imposed? Joe PS: I'm now really curious to know why this is not available now! _____ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, Lj Sent: Monday, August 26, 2013 4:09 PM To: arslist@ARSLIST.ORG Subject: Re: Sort of a Rant: Quote from Dev Studio Help - "Web applications do not support the $FIELDHEL$ keyword" - WHY??? ** No, I don't know the answer to which you seek...but I can hypothesize?....:) Ok...so field help can be 'bulky' at times....and the client (web browser) doesn't keep a copy of the form in question in the same way that the user tool did...so to try to keep the communication size between client/mid-tier/server as small as possible, as well as keep the Mid-Tier cache smaller, it was decided to not include the 'help' for each and every field on each and every form in cache, and transferred across the wire just a guess though...I certainly don't work for, nor represent BMC on this, nor ANY matter....but my explanation makes sense to ME :) On Mon, Aug 26, 2013 at 2:04 PM, Joe D'Souza <jdso...@shyle.net> wrote: ** Does anyone know the reason why the Mid-Tier is unable to support the $FIELDHELP$ keyword? The help on this keyword states that "Web applications do not support the $FIELDHELP$ keyword; it returns NULL." Any reason why this would have been hard to implement on the Mid-Tier? I was hoping to use it on a very small form wherein I could set $FIELDHELP$ to a temp display only field on every gain focus action of a field, displaying the help of that field in that display only field. Works like a charm on the User tool, however it does not on the Mid-Tier because of this said limitation of the said keyword. With the impending slow death of the thick client, it would have been nice to have features such as this available at the Mid-Tier level as well. If you ask me this feature would have been more useful on the web for intuitive field help for a end user, than it is on a native thick client.. Joe _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
