Hello everyone, i’ve met one problem many times with enabling “Multiline” option in parameters. Changing “Multiline” option gives no effect for text boxes in request forms (source of type “Text”) and, importantly, for sections. Tis too hard to add “Integer” tables for report with only purpose to do multiline text. Maybe i’ve missed some option in parameters, perhaps some hotfix or service pack, but question is still pressing. This option works only for “Label” in request forms. (NF 3.60/3.10 SP3) Can anyone help me to solve this problem? Many thanks in advance, Anthony
I’ve used multiline textboxes in v3.60 without difficulty. The only real issue I have is when editting the field, it reverts back to a single line. Frustrating when you want to edit the middle. One thing you will not get setting multiline=True is scroll bars in the textbox. Those don’t exist.
Hello mr. Webb, perhaps you are talking about forms but i’m about request form of reports. Currently i support end user database on NF with corresponding license restrictions. Usually all necessary customisation i have to implement are report tuning for different purposes. So it causes specificity of my questions. Reports’ request form is more simple then “Form”. And what i see in the widened table tis huge cursor with the width equal to width of the box. Text string is in the middle, and table box option ‘Multiline’ settled correctly(?). Maybe inapplicability of this option for reports is one of restrictions for this forms, maybe i something missed. As to report html-sheet, i surely know that it perform line folding. In any case for table footer. For table body/line i was unable to repeat this effect. For instance, C/AL CR symbol was replaced by some pseudo graphic symbol (it may be different for various language Windows versions). So, i’m quite sure, that it may be done for reporting sheet but just need some hint or tip how to handle it better. Thank you for your input, Anthony
Just a few observations:
- The property VertAlign must be set to Top (not default ).
- The wordwrapping won’t take place until you leave the control. In other words, if you only have the one control you’ll never see the wordwrapping (since focus never leaves the control).
- The BIG cursor can’t be avoided I’m afraid - This goes for “normal” forms as well.
All in all - as far as I can see it - the behaviour is exactly the same in reports as on forms. Out of curiousity: Do you really need this functionality on the req.form? Anyway, Posting No. 100 [:D] - Hope it was helpful [;)]
But it is true that RequestForms on Reports/Dataports are not exactly the same as standard Forms. I know one difference which is REALLY annoying, but I am not sure if it is the only one. The ParentControl property has absolutely no effect on a RequestForm. This makes Frames and TabControls completely useless, because controls will not retain this property after saving the Report/Dataport. What happens is that you design the RequestForm with (for example) a TabControl, having several other TextBoxes or Labels inside it. The first time you save and run the object, the TabControl will behave properly. But if you now enter design again, all the control will be directly on the RequestForm, ignoring their parent TabControl. PS: congratulations Steffen [:D]
Thx Nelson,
quote:
The ParentControl property has absolutely no effect on a RequestForm. This makes Frames and TabControls completely useless, because controls will not retain this property after saving the Report/Dataport.
I’ve just fiddled a bit with this (always the sceptic [:)]) and, actually, as I see it, it’s not the ParentControl property that fails - it’s the InPage property. In a TabControl the InPage Property has the value 0 on tab1, 1 on tab2 etc. After saving/reopening a report/dataport it will revert to 0 for all controls - and, thus, in effect move all controls to tab1. Conclusion: Don’t use TabControls on RequestForms, however, I don’t see any problems with regards to Frames. I hope kopyurff will forgive us from straying off topic [:I] … correction … If you delete a frame from a Req.Form, apparently the contained controls are deleted as well, but actually they’re not [:0] Oh well, just another Navision quirk we have to live with [^]
Ah! [:I] I was just checking your knowledge, Steffen… [:D]
quote:
Originally posted by Steffen Voel
it’s not the ParentControl property that fails - it’s the InPage property
You are right! I just took a closer look. But the idea was that the result is very stupid. Interesting point about the Frames, I could swear they had the same problem - maybe I dreamt it…
Thanks all for your inputs. It truly works, but with interesting pecularities - when string reaches end of the box it becomes ‘non-multiline’. Truly, the cursor was only big and box was insufficiently widened to display multiline text properly (as needed). As i understood, this system pecularity cover and html-sheets too. I.e. it does not support sections lines/bodies with dynamical width which changes with the number of text lines. Embarrassing fact. What about my experience with tabcontrols. This control works and looks properly at run time but not in the designer. All tabcontrol items drop on the first page and any change in report cause ‘this fact validation’. I’ve asked this question in neighbouring forum already (http://www.mbsonline.org/forum/topic.asp?TOPIC_ID=8769 - it sank silently). And surely it is better to move dialog from tabcontrol before deletion. One this mistake may oblige to delete all dialog items to remove error with unvisible box, for instance. Tis truly useful, thanks SV. And what about other questions. Necessity and opportunities to use this option. E.g., if it needed present 1024 text string - quarter of ordinal page - why don’t use this multiline option? The Req.Form are not complicated in structure almost in all cases. It more convenient to use Forms. And last. The combination of native customisation from Microsoft and customer customisation causes great differences in daatabase structure. i didn’t find ‘Posting No.100’. BR, Anthony