Cut selected lines?
So I got the task to update some C/AL code in Navision today, and got introduced to it's built-in editor. First thing I noticed, it doesn't support tabs. At all. Pressing Tab will helpfully move the cursor to the next line, and pasting text containing tabs will make the editor display stuff wrongly (there will be no visible indentation, but all characters will be offset by the number of tabs in front of them). Anyway, here's one of the gems I found:
Similar message if you try to delete. Selecting some text and pressing Ctrl+C followed by Ctrl+V will make the line that was in front of the selected text appear behind it.
These are the discoveries I made in the first 10 minutes using the editor... (which reminds me, why haven't we seen any other Navision WTFs yet?)
hallo_amt last edited by
I saw once a project where the admin had to enter the users password to be able to delete him. next to 'delete user' was 'change password'
I never understood that.
SpoonMeiser last edited by
When you say "doesn't support tabs", I was assuming that there was no decent GUI for handling multiple open files.
An editor specifically for editing code that doesn't work with tab characters... Wow.
I think the image really sums it up though. I can't begin to imagine how annoying that it to use.
All of this is caused by the editor (like everything else in Navision) being developed in C/AL itself. The code editor is little more than a specially drawn table, and you'll usually want these things when dealing with normal data - but as a result the code editor suffers from the same things. For example, multiple lines don't always go where you intended when you paste them, and you can't replace entire lines with it. You also can't select from part of a line to part of the next - if you cross lines, you can only select whole lines.
I've been developing in Navision since February, and there are indeed plenty of weird things. For example, since I'm in Denmark, we usually develop on a Danish version of the Navision client (the IDE is still in English, but the rest is Danish). When you bring up the properties window for something and alter a boolean value, you select it and type Y(es) or N(o). However, there are two ways of "saving" the value - you can remove focus from that text field, or you can remove focus from the MDI form. In one case, it'll accept the English names - in the other, you need to use the DANISH name (Ja or Nej), causing an error if you typed Y for Yes - best of all, it EXPLICITLY states that the valid options are Yes and No. The value is never formatted in Danish in the property editor - the only time you can use those names is when you're using Danish in the general environment, and want to filter on a boolean.
You can't copy menu items, but you can copy nearly everything else. This bug has always been there.
On a report, OnPreSection and OnPostSection both run *before* the section is actually printed.
There's also a compiler bug experienced when copying a field with a table relation between versions 4.0x and 5.0 (any direction) - a bug you might run into while upgrading a customer, without even noticing it.
Usually, when you copy an entire field, all of its properties follow it. That's a good thing, because you usually want those to stay the same. Usually, when you compile a table relation to a table that doesn't exist, you'll get an error (since you normally type the name, rather than the ID) - but if you just type an ID, it's okay - it won't bitch, because it has all the info it needs to enforce it when it has to (and you can create the table after that).
The bug is that for 4.0, they changed the clipboard format to include a hidden structure containing the ID as well. When it then goes to compile this complete table relation, it will notice that there's an ID, so it has all it needs. However, it then proceeds to search for the table by name - which will fail, since it doesn't exist yet. However, the compiler still doesn't bitch about it - it just notices there was an error finding the table, and therefore doesn't re-assign the structure they use to store this table relation. That structure then ends up being used as the table relation compiled into the object - which will be the last table relation it's found.
The workaround is simple, of course - just import the custom tables before you adds fields to the standard tables - but if you don't do that, you'll probably not notice until the customer has already been upgraded, and they call in with a weird error message. Depending on the field that's messed up, that may take quite a while.
Hopefully, 6.0 will fix things up when it ships in late 2008 (unless they get delayed AGAIN) - of course, that assumes people are willing to switch to the new client they're making. I might never know, since I'm planning to go to a university in the beginning of 2009.
(BTW, I can tell that's either Navision 3.70, or one of the 4.0x's. Which one, I can't say, as you haven't included enough context, but considering the FIND('-'), that piece of code likely wasn't written in 4.03 - FINDFIRST would have been more appropriate.)
It's Navision 4.0SP3, and the code wasn't written by me. I came to the conclusion that the editor is really a table myself after using it a bit more. Why the hell does Navision have to implement everything as it's own custom controls that don't behave like anything else in Windows?
And SpoonMeiser, when I said that tabs aren't supported, I meant that tab characters aren't supported. This abomination reminds me of Oberon we used in the first programming class at university.
I think there are many reasons for that. One of the biggest is likely that the current GUI started out on Win 3.1, and many of the things it needed weren't available back then (not in a form they could use, at least). Very little has changed since then - bugs have gone unfixed because other VARs relied on it for something, there are strange methods you have no use for (OnTimer on a form?), and apart from adding a real debugger, most changes to development have been made in order to better accomodate using MSSQL for the database server (FINDFIRST/LAST/SET in 4.03, and KEYGROUP* functions in 5.0).
It also needs to do on-the-fly data conversion, since it stores everything as ASCII, rather than ANSI or even Unicode, which might also be one of the reasons they re-implement all controls (another WTF caused by its DOS legacy). This adds to the aggravation when you do file import/export using dataports or reports, since you need to do your own conversion at that time (it's a trivial thing to add once it's been written once, but it's annoying).
(Of course, the REAL WTF is the scrollbars they used in the *really* old versions - you had two up and down buttons, one for moving a line, and one for moving a page, with no "handle" to indicate your position or allow you to jump more quickly between rows. I'll post a picture if you want, but I can't make one until I'm at a computer with XP, as only 5.0 will run on Vista.)
Speaking of data imports, the company I work for used to have it's own accounting software (written in clipper), and we supplied it to an accounting firm. This accounting firm started moving to Navision at the end of last year (with our help), and I'm the one that has to import data (which is exported from the DOS program by somebody else). One of the problems we faced when transfering the data was that Navision's columns are more limited than the DOS application's were, so descriptions had to be shortened on a whole lot of items. Then there is the import procedure (which was set up by an outside Navision expert; they also specified the format for export from DOS application), which includes a lot of manual importing from text files (with fixed-width columns), then transfering this from intermediate to work tables while manually clearing some other tables. There's only a hundred or so companies to transfer.
About scrollbars, I noticed that the mousewheel randomly doesn't work, and that there are severe painting problems in tables. Also, why isn't there a single form that wouldn't have at least 1 label truncated...
One of the list forms probably has that, but apart from that, I have no idea.
Here's another WTF: in reports, you can tell a header section to print on every page - causing erratic behavior if it's not supposed to start before page 2. The solution? Modify the current page number just after you finish the last section before your header, and use OnPreSection to only show the header if the page number exceeds a certain value. Best of all, since they don't know if anybody is relying on that behavior, they can't fix it until the new client appears.
As for the images I was talking about... V1.10 is the earliest I have, and this is what scrollbars look like:
They didn't change this until V3.10, released 5 years later:
And best of all, V3.01 *has the same scrollbars as V1.10*.
Hey, I've seen scrollbars like this - in a dictionary application originally released for Windows 3.1. The 32bit version replaced them with more normal scrollbars (though the list still behaves somewhat differently from normal lists in Windows).