ArcherPoint Dynamics NAV Developer Digest – vol 74
As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.
Faithie Roberson on converting a classic layout report to RDLC:
When converting a classic layout report to RDLC we sometimes run into report request forms that had a button control to do a lookup of some sort of related data. This button control can be replaced with a field made non-editable and a LookupPageID assigned. BUT – it looks like a field to be entered or changed on the request page. (See example below). A better method is to create a lookup text string. This provides a bold blue hyperlink-ish title, like "View Statement Text", that is intuitive to the user. And it's easy to do:
1) Create a Text Constant global and assign it the value you want to see on the request page (like "View Statement Text").
2) Add the field to the request page. I usually give mine a control name that is meaningful so that when I open the code page I know for certain which variable I'm dealing with.
3) Set the properties for the request page variable as follows:
Editable = FALSE, ShowCaption = NO, Lookup = YES, Style = StrongAccent.
4) On the OnLookup Trigger of the request page field, create a local variable for the page you want to access for lookup.
5) Add two lines of code to the OnLookup trigger:
An example below shows what it looks like:
Figure 1. Converting a classic layout report to RDLC.
Carrie McNally shared advice from Mike Cohn on sprint planning:
Some advice from Mike Cohn @ Mountain Goat Software:
I want to address a pair of questions I’ve been asked a few times about sprint planning. The questions are:
- Should testers participate in sprint planning?
- Wouldn’t sprint planning really be more efficient if done independently and we just met at the end to add up everyone’s hours?
To address these, let’s look at the two purposes of having a sprint planning meeting:
- Collaboratively selecting a set of product backlog items to work on
- Having a rough idea of the work to be done to deliver those items
Each of these is best achieved by having the entire team present for the entire discussion. So, yes, I want the testers (and any other role you might want to ask me about) present.
The argument I hear in response to this is that the discussion gets highly technical and testers can’t follow. They slow the meeting down, and it’s a waste of their time for them to have to be there.
Well, the meeting should not be getting that technical for that long. Remember the purpose of the meeting above. The goal is a rough idea. A perfect plan with perfect estimates is not needed.
Further, there will be times during the sprint planning discussion when the testers may be able to answer questions. If they were not participating, the whole process would be less efficient.
As for having individuals split up, do sprint planning independently on their own, and then meet just to aggregate work, this loses all benefits of considering the work as a team. While this may seem efficient in saving hours spent in meetings, those savings almost always prove a false efficiency when issues arise during the sprint that could have been discussed during sprint planning.
The key is keeping sprint planning as short as possible. To do that, stay focused on the two purposes listed above.
If you do that, you’ll help your team succeed with agile.
Tina Terrezza shared ChargeLogic’s video:
Find out about what’s new with ChargeLogic in this entertaining “news broadcast”
If you are interested in NAV development, check out our collection of NAV Development Blogs.
For step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV, see our collection of How-To blogs.
If you found this post useful, you might also be interested to read through our archive of the Dynamics NAV Developer Digest.