Implement WaldoNavPad in NAV2009

I don't know if you already know, but a long time ago (actuall back in about 2004), i created some kind of cool tool. It is a tool to be able to handle big amounts of text in NAV. Not with a BLOB, but with actual text fields, to be able to use this text on reports or to be able to apply filtering on the text. So in fact, the navpad is going to cut down your text, but not in the middle of the word. No, it's going to do that with a little bit of intelligence: on a space or carriage return.

How did it all start?

May be for those of you (probably only one or two of you ;°) ) that are interesed: how did I come to this? Well, I didn't wake up in a morning with the idea: I'm going to create a navpad in NAV. I want to be able to handle big texts. No, that's not the case. I was actually doing an implementation where I had to convert MS Access-data to NAV. As you know, Access has Memo-fields .. and this particular customer used it extensivly.. A HUGE amount of memo fields.

We had to be able to filter and search on the data, so I couldn't import it into BLOB fields .. and we were not talking about bigText, AddIns .. yet (it was a 3.70 implementation). So I came up with the idea to use .NET code where I could load a huge amount of text in, and get pieces of text out.. . The navpad-business logic was born. After that, it was a small step to create the navpad as it is now .. by creating a simple form on top with a RichTextBox .. and some code in NAV.

And now?

Over the years, about 6000 people have downloaded it (or let's say: it was downloaded about 6000 times by one person :-) ), and it got a lot of attention on Mibuso .. I even ended 2 times second in the download contest :-). I also got in touch with quite some people that were implementing it in their addon.. . So I guess, it was useful to say the least..


Since NAV 2009 arrived, there are a few questions that needs to be answered.. . Is the tool still useful? Is Microsoft coming with their own solution? Do I have to make some kind of AddIn for it? .. and may be there are some more questions you have, which I would like to know as well.

I have been thinking about it, and it doesn't seem useful to me to create an addin for it .. because the whole idea is: being able to filter the data, and being able to print it on reports. AddIns doesn't have anything to do with that. If I display the text in an addin, sure it would be easier to handle the text, but it wouldn't be possible to filter the text, would it? Now you can just display the text in a standard repeater, and it's still pretty nice formatted. If you think otherwise, please just tell me, and I'll work on it.

New Release

As a test case, I implemented the navpad in my own company database, which is on the RTC, and it definitely is still useful (at least for us), so I decided to polish the tool a little bit. And I got some unasked help along: Alexander Houzet implemented it in his database, and he sent me some bugfixes and a new contextmenu. Together with that, I implemented a new "management-codeunit", which is actually some kind of a proof-of-concept in Development Standards.

What i tried to do is to write some kind of interface-codeunit by mapping all necessary methods and properties. The idea is to only use this codeunit, and not heaving to use the automation among your business logic. You know the typical mistakes: wanting to change something on the business logic, not having installed the dll, and you're not able to compile. This kind of codeunit avoids this situation, plus, you have the chance to write your own, understandable interface. Everyone can use a codeunit, but not everyone is capable to use a dll... . I know that probably a lot of you are already implementing it like this, but I didn't (at least not back in 2004 :-) ).

Anyway, these bugfixes and codeunit addition ended up in a version 3.1 of the waldonavpad, which is downloadable from Mibuso as we speak .. and i hope I get lots of feedback to be able to extend this tool as good as possible.


Comment List