Newcomer Questions

Hello everyone, We are in the process of purchasing Nav 2.6e and we’re evaluating Navision’s language while we are waiting on the lawyers… Old Delphi/VO/VB/Clipper developers here. We are going with 2.6e due to some advanced distribution issues with 3.x which are supposed to be fixed in the spring. Anyway, I have a few questions for everyone concerning the basic language and if 3.x may support some of these things: 1) Can variables be assigned dynamically? for instance, can an array be dimensioned dynamically? Can an option variable be assigned via code? etc. 2) I did find some properties available for controls using the symbol menu–none related to the value stored in the control. Is there any way to assign a value to an unbound text box via code? Don’t particularly want to create a temp table to manipulate information in a simple text box. 3) If form.control properties can not be accessed via Nav code, is it possible to get a handle to the window and manipulate via Win API? From what I’ve seen so far–we’ll be working a lot of ActiveX DLLs… I have found the ActiveX (or automation) stuff works real well (ADO, Excel, Word, etc.) Thanks,

Bill, Let’s start with a few general comments: - The C/AL programming language is NOT a general-purpose development environment like Delphi or VB is. This means you will have to accept that some things you are familiar with, will not be available (i.e. hDW values or API interfacing in general). On the positive side is that many things you have to code yourself in the other enviroments are readily available for you in Navision, in special of course functions concerning database handling. - Please do remember that the function of C/AL is to give you a tool for customization of the Navision package. Although you can do amazingly many things with it (once you have mastered it), C/AL is not intended to be a development platform for a full fledged “new version” of Navision. - If you require more control, please do have a look at C/FRONT also. This might be a better alternative for heavy duty interfacing stuff, as you can program in C-style there and have access to/control over many more things (but you are much more on your own as well, i.e. error handling will be your task, and C/FRONT is much less forgiving) - Please realize you will be modifying a thoroughly tested, carefully designed software package where almost everything is related to each other in one way or the other. Also, don’t expect to get extensive documentation, flowcharts or (entity) relationship data on the innerstructure of the Navision database. It’s not existing, or not made available. - Without doubting your programming skills in any way, be warned that although learning the C/AL language is fairly easy (in special for someone with Pascal experience), knowing the proper syntax is about the least important side of development. Far more important is knowing what is done where, why and how, and what would be influenced by modifying the core tables or codeunits. Are your programmers also capable to foresee the accounting consequences of a modification? Looking at the information you are providing, the impression is that you have a couple of interesting challenges. To my believe, many NSC’s (Navision Solution Centers) would start shivering a little when you would confront them with these requirements. Please make sure you are dealing with a NSC that handle your situation - take my word: you will need a lot of support. With the proper NSC you could make an agreement to have i.e. the core-development done by the skilled programmers from this NSC, while your own programmers are assisting while learning, and could take care of the easier parts. If you need advise, I can recommend a NSC to you… :slight_smile: John

quote:


Originally posted by breese: … 1) Can variables be assigned dynamically? for instance, can an array be dimensioned dynamically? Can an option variable be assigned via code? etc.


Nope, you cannot dimension dynamically arrays… but usually you can use that functionallity by “emulation” using temporary record variables (instead of having an undimensioned array you’ll have a virtual table…).

quote:


… 2) I did find some properties available for controls using the symbol menu–none related to the value stored in the control. Is there any way to assign a value to an unbound text box via code? Don’t particularly want to create a temp table to manipulate information in a simple text box. …


You can use variables for showing values in the control and using them in functions for storing data in the database or showing information to the user.

quote:


  1. If form.control properties can not be accessed via Nav code, is it possible to get a handle to the window and manipulate via Win API?

Only a few properties can be accessed via C/AL when refering to the form controls… it’s better not to use external handlers with the windows. If you prefer using your own “system” you can always use C/Front and make your own interface to the application…

quote:


From what I’ve seen so far–we’ll be working a lot of ActiveX DLLs… I have found the ActiveX (or automation) stuff works real well (ADO, Excel, Word, etc.)


Yup, but remember that visual Activex controls are not directly allowed for being used on Navision (example a calendar ActiveX control for inserting on a form…). If you’ve been programing on Delphi and/or C++Builder/Visual C++ you’ll find that is not really hard to start programming on Navision after a few weeks of trainment.

quote:


John Tegelaar wrote: If you need advise, I can recommend a NSC to you… :slight_smile:


Let me guess… let me guess… well… i think i can also recommend them another one that doesn’t start by A… :). Happy christmas and happy new year, John. :slight_smile: Regards, Alfonso Pertierra (Spain)apertierra@teleline.es I forget to say… MERRY CHRISTMAS AND HAPPY NEW YEAR TO ALL… :slight_smile: Edited by - apertierra on 2001 Dec 20 08:07:19

John and Alfonso, Thanks for your inputs. Yes, it does seem to be a challenge, but we’re quite motivated and think we’ll be able to put together some great things. My programmers (me too) will be working right along side our NSC reps. We intend to build a list of requirements during the Discovery process and then we’ll split up the tasks between our local talent and the NSC. I’m positive that Navision will help our business and even more positive that we’ll be able to use “what ever it takes” to ensure our users (about 300) get the style and flexibility they are accustomed to in our VB/Delphi/VO/Clipper apps. Thanks again, Bill

Bill, Without knowing the kind of application you are to be developing, please do keep in mind that Navision (Attain) is based on workstation (“thick client”) technology. Having some 300 users simultaneously might generate a lot of network traffic, which may lead to performance problems. It’s not unusual to switch to a Citrix environment in such case, which gives you “thin clients” and takes the burden from the traffic-load. Also do know several additions have been developed already to separate the (multi-user) input from (central) processing, usually by using web-based entry. Take, for instance, a look at the InfoStore product from the Icelandic company Strengur (www.strengur.is). John Alfonso: Thanks and the same to you and all others.

John, Thanks. I really appreciate the non-NSC type responses you (and others) provide and I’m really starting to like this forum. Unbiased/honest responses on a forum such as this will certainly drive user/developer interest and I think would encourage more to participate. We are in the very beginning stages of our Navision journey and I think you’ll see quite a bit of input from us based on the way most folks react/respond on Navision.net. We have some very talented folks–so, watch for some great things from them as we begin to optimize our Navision experience… Back to your last input, here’s where we are and what we will be doing over the next few(?) months: We have about 33 retail glass shops, 5 distribution centers and a fairly extensive administrative group. We are currently hammering our Citrix Metaframes with transactions from several existing program languages including Clipper, Visual Objects, Delphi, VB, etc. Obviously the overall goal is to cenralize all financials into a single system. We’ll always have to support other systems hitting our data, that’s why we opted from the beginning for SQL2000. Phase 1.) We will customize Navision (SQL2000) to meet the immediate needs of our distribution centers. Major customizations will include an interface into our US standard glass part numbering system, provide interfaces to existing corperate GL, Procurement, etc. systems, eventually provide EDI capabilities. I completed the interface into our glass part numbering system already. The automation interface simply provides a wrapper for the 30+ tables that contain the national part numbers, vehicles, desciptions, etc. It is what I beleive you all term as (sort of) a bill of materials. The users roll into our automation object, select a vehicle and the object returns all the (user selected) parts required (a bit more than that, but I think you get the idea). The key here is to limit the number of table$ that must be rolled into Navision and optimize SQL performance via ADO or whatever works best. Right now ADO is working great! We’ll also develop a standard library (in Navision and VB) so we’ll be able to optimize code reuse. Phase 2.) We’ll roll in our Call Center operations, glass shop point-of-sale operations and our administrative areas. A lot of customization work here, but we’ll minimize it if we “think smart” during phase one… Can’t wait to dig into this–got to make the decision to actually buy first… Lawyers–ugh! Thanks again. Bill

Bill, Thanks for your kind words. Good to read you appreciate the attitude of the participants of this forum. Feel free to throw in any question, and be assured of getting a response in no-time. In fact, most -if not all- of the forummers who provide the majority of the answers to questions are professional developers/programmers/consultants themself and know for no other the (im)possibilities of Navision. And yes, the atmosphere on the forum is friendly and very forgiving. You’ll notice a warm and enthusiast response, in special to challenging questions :slight_smile: Using SQL2000 as platform is a good choice when it comes to interfacing. This is even the main reason for selecting it. With SQL you have many standard tools available to pump data in and out. Our general approach in situations where Navision is the spider in the web of connections, is to use a set of dedicated interface-tables on SQL to exchange data. Let an external application write its data into the interface-table(s), then let Navision pick up this data and do the processing/validation on it. And vice-versa, of course. The advantage of having separate tables is, for example, the possibility to run Stored Procedures on these - whether or not triggered by the SQL Scheduler for automated updating of the data. Or you can quite easily communicate to/from a web-site using an ODBC bridge (take a look at www.easysoft.com for a good one which allows multi-users over a single connection). Believe to speak for all other forummers when I wish you good luck in your upcoming discovery journey into the world of Navision. You’ll find many interesting points, will get amazed by what flexibility you have at your hands, and you’ll discover there are few to no borders. John