Let’s face it, if the people who developed the Navision executables had to rely on a debugger like the one they gave us, they’d still be working on getting their first beta out the door. And, if this were medieval times, all the medieval programmers would invite the developers to a stoning, or least cast aspersions on their lineage. However, I don’t think I’ll ever see a good debugger in Navision in my lifetime, but I would appreciate one that at least is fully functional! The following are my take on minimal requirements to complete the debugger: #1 At least support arrays! Even a simple ZOOM would be nice. #2 Don’t make the Zoom, Table Filters, and Sorting windows MODAL! Especially Zoom! It makes it extremely difficult to watch a field. #3 Dialog windows should not be modal in debug mode. They plunk themselves in the middle of the screen, on top of everything, leaving precious little space for all the debug windows. #4 Breakpoints. There has got to be a way of allowing the user to set a breakpoint without requiring them to step through the code in debug mode to get to the line. #5 Show call stack info. Like breakpoints, the only way to tell how you got to a line of code is to step through all the code in debug mode. How about providing a method for displaying the all of the routines called to get to the current point. #6 The Debug Window. In a normal debugging session, what’s going to happen next is as important as what just happened. The debug window seems to insist on placing the line about to be executed at the bottom of the window. It would be enormously useful if it instead kept the current line at the CENTER of the window so that the next few statements can be seen. -jp
C/side gives to me the impression being a tool enabling moderate changes. I agree, that C/Side has not the comfort as other Dev-Tools. However, I don’t think that it should further enhanced. Why that? Well, we are now in the time of Com and Com+ objects and I don’t think that C/Side might become in short time a tool having all we find actually in VB or VC. VBA for example can be implemented By Navision as well. It’s only a question of licenses between Navision and Microsoft. Well, this of sure would further imply that we have no more Pascal like style and have to change into VBA. Hence, why not to have two realities. C/Side for fast implementation (maybe for a transitional time period) and C/Side-VBA for enhanced programming? SY F
Don’t get me wrong, I would LOVE to have Navision throw out C/Side and replace it with a REAL language, like VB, VBA, or even VC++! Then they would also have to throw out the current C/Side code base(s), and rewrite it in the new language. But I’m not holding my breath until that happens. In the meantime, we have a very large existing C/Side code base, and a significant amount of development and debugging will be done in the C/Side environment. So I have to disagree, as long as we are stuck with it, they should enhance C/Side. A LOT! -jp
While talking about letting loose C/SIDE (with C/AL) and replacing it with a standard language it worth looking to Navision’s competitor here in Denmark Damgaard. With Damgaard’s new system Axapta they replace their extended application language (XAL) with Java. Ever since they introduced Axapta they have had problems selling it, primary due to the fact that except a few companies, then noone really know Java or how to program Java. 1000’s of solution centers (and even more programmers) know C/SIDE. They might need to learn the system all over. Of cause it would be nice for new users if Navision would allow you the choice of either C/SIDE or eventual VB for Applications. ============ Best regards, Erik P. Ernst, webmaster Navision Online User Group
To be honost, I am not really a big fan of C/Side but i must say that it’s simplicity and it’s implementation makes for a stable platform. The more things you implement the more things that can go wrong. For that C/Side is good. It may not be the most convienient choice but for now it’s a solid one. I would think that some minor modification to the development side (Better debugging facilities, Auto complete VB, VC++ Style and easier property management) Would get us a long way