Hi
I’m new to this
I have a FlowField with Lookup that returns multiple values
how do i concatenate the returned multiple values in a single comma separated string to display on the item card
Thanks
Nik
Display multiple values from flowfiled as concatenated string on page
C/AL; Flowfields; Flowfilter
You can add values in a local variable from the filters & show them.
Hi Manish, thank you for the response.
Let me know if this is the right approach.
So my FlowField is Called “Catalog Pages” it is a FlowField with Lookup to another table that contains catalog pages.
Lets say for No. = 1 it returns 1, 2 and 3 as values when looked up on Item Card
On Item Card page i declare a local variable _Catalog_Pages
do i write the code in the C/AL for Catalog Page - OnLookup or No. - ?
can you point me to an example?
ok
So i did some reading
and
Created variable for the recordset and for the string on the item card page
and did this code in the OnAfterGetRecord()
// TEST CATALOG PAGE
//_Catalog_Pages - Record variable
//_Catalogs_String - Code(50) variable
_Catalog_Pages.SETRANGE(“No.”,“No.”);
IF _Catalog_Pages.FINDSET THEN BEGIN
REPEAT
_Catalogs_String := _Catalogs_String + ‘,’ + _Catalog_Pages.Page;
UNTIL _Catalog_Pages.NEXT = 0;
END;
_Catalogs_String := DELCHR(_Catalogs_String,’<’,’,’);
is this the right way to do this? is this the right trigger to use? will this create huge performance issue? is there a better way to do this?
should i put this into a global function so i can call it from other places (like “Item List” or on other pages like fact boxes…)
Thanks for your help, this is only my second day working in NAV.
You need to add the values which you need to show on the form.
First of all, that cannot be a flowfield. Second, that is not the right trigger either. Personally I would create a function in the Item table that returns the string, so that you can create a textbox on any form with the function as its source. That way it behaves the same on all Item forms, and you would not have to write any code on any form, which is a bad idea to begin with.
Also, drop the underscores, they are distracting. You should also read about naming conventions in NAV, and use those in your development (plural in table names for instance should not be used). You will thank yourself later when you have to maintain this code.
i was thinking about that approach as well, but have no clue how to achieve this.
I create the string global variable and the record then create a function that will assign the value to the string.
Which table trigger should i use to call the function in the item table?
I want to have functionality then in pages, where the string is linked to the catalog page table. so the user can add or delete records that pertain to that item number.
So, putting the “How?” question aside for a moment, can you explain WHY you want to do this? What is the objective? Talk in terms of the business requirement that you’re trying to meet rather than in terms of the solution you’re proposing.
I ask because sometimes we get so focused on the shovel that we forget about the purpose that the hole is intended to serve.
to mirror our existing UNIX based system
default nav requires way too many drill downs for the user to retrieve specific information. we want this to be available right on the item card or item list as the users will not have time to drill down for every information that they require.
what i want is working with the above code, i was just asking whether this is the right approach from development point of view, I’m not asking for business advice.
Well I would take a completely different approach. Nowhere in standard NAV will you find such a concatenated string, it would look like something that does not belong in NAV. Making it look/feel like it belongs in NAV, you would simply have access to the Catalog Pages from the Related Information menu on the Item Card, and that would open the catalog pages page filtered on the Item number. If it is something that is really important to have easy access to from the Item Card, you might think about adding a Count type flowfield that shows the number of related Catalog Pages, and through the drilldown property it would automatically open the page that is defined as the drilldown page on the catalog page table.
Most of this type of thing can be done without writing a single line of code. You should learn how to properly use the application, and talk to your senior about how to approach this. This forum will not properly teach you how to do this.
I understand that and done that already, but the users do not find it very “user friendly”, the business requires the information to be right there in front of the user.
I’m trying to make it work the way the business demands from it to work, the business logic should not change to adjust to NAV but the other way around.
Hi Nikola,
I would never presume to give you unsolicited business advice. My reason for asking why you were doing this, as opposed to offering an opinion on how you’re doing it, was so that we, the people of whom you’ve requested input, would have a better understanding of the true purpose of the feature. Absent that information, we are all simply typists.
Now knowing your intention, I can second Daniel’s observations. I too believe that it is essential that you have a solid understanding of the strengths and shortcomings of the NAV platform before you undertake to make your Porsche look and feel like the VW Beetle that you’re upgrading from. (No slight intended, I loved my blue Bug. 
).
As with any application, you would probably want to strike a balance between the amount of data displayed in a UI (too little requires extra keystrokes, too much burdens the user’s mind) and the keyboard burden you put on the user (too much and you slow the user, too little and you slow the system).
Adhering to NAV coding standards and best practices shouldn’t be seen as a burden, but rather a method that will enhance the likelihood that your code will be structured in such a way as to optimize the outcome. Put another way, the standards aren’t there because MS like to publish rules, they’re there because experience shows that these are the best methods for doing certain tasks.
Regarding this specific task, NAV’s best design would have the user opening a drill-down form with a mouse-click or hot-key keystroke. If you’re bound and determined to put this data directly on the Card, a sub-form control would be preferable to the string you’re trying to build. It’s far simpler to implement, and it wouldn’t suffer the inherent limitations of a string (your data will eventually exceed the capacity of the string to contain it, the string is lifeless; you can’t do anything with it other than read it, etc.).
Just my opinion, which is, I believe, what you were asking for?
Cheers,
George
Thanks George,
i love my bug too, never driven a porsche so i don’t know what it feels like…
I do understand where you guys are coming from. But you also have to understand that every company does not have the same business model. There is no such thing application that will make everyone happy and the developer has to make the system functional, regardless of the technology in use.
My original question was. can this be done. Now I know that it can be done. Anything has a cost we just need to weigh it and find out if it is justifiable or not.
One thing i know is there is no such thing as “it can not be done” is always just the matter of how.
All the Best!!![:)]
Hi Nikola, do you have time for one more question, just to satisfy my curiosity? How do your users make use of this list of catalog pages on the Item Card? What conditions would cause the user to read this data, and what would they normally do after having read it?
My first thought would be that they are answering someone’s question about where in the catalog to find a particular item, but I’m really curious to know for sure.
One other thought for you too, on the “how to do it” topic. I noticed in your screen snap that you’ve listed the same page twice. If I were writing a function to build that string, I’d probably try to avoid redundant values. Just a thought.
Sure no problem,
When customer service is on the phone with customers, they might reference the page so they can take a look at the item picture. customer service might go through several (hundred) items over the phone with the customer so all info regarding the item (inventory or marketing related( has to be in front of the user. whether that is on the item list (in the list or in a fact box) or on the item card. every extra step to get to the information is a waste of time.
Again regardless of what is “the right way in NAV” we have to look at the business needs.
the second field that you are looking at is is the original table field that was originally added by someone else, probably thinking that there can only be one catalog page…
it will no longer be there (the screenshot is from test environment), the field is a flowfield that will do count. OnAfterGetRecord() will call the function that concatenates the string only if the value is greater than 0 (some items are non catalog items).
I can go a long way down this road of making the program more efficient, and I even agree that the sheer number of drilldowns can definitely be a bit too much, especially with high volumes of data.
A few things I want to point out:
Don’t spin advice that you get in this forum into “unsolicited business advice”. Nobody in here is suggesting any changes to the business. I’m only trying to help you implement a solution for the business need in a way that fits in with the application. That’s not business advice, that’s advice from someone with close to 15 years of development and implementation experience with NAV.
You asked about whether this is the right approach, so you should expect opinions. In my opinion, you are taking the wrong approach.
I value your opinion,
thank you for your help.