Hi
I'm trying to make NAV a little object oriented. I have made a CodeUnit representing a main message and a bunch of other Codeunits representing some specific submessages.
In the main message I can hold up to X submessages of each type.
It works pretty well.
BUT, a thing that would be really awesome is if I can get some more generalisation or polymorphism here. =P~
So, is there anyone who knows if I can do an array of variants representing the submessages and then call some common functions for all the submessage objects? Is it even possible to do some conversion back to codeunit when the message is stored in the variant. Is it possible to test which codeunit that fits in the stored variant?
I know there is a ISCODEUNIT, but it's obviously not enough. :-k
0
Comments
So far I haven't run into anything I couldn't program in Navision, so I don't see the need for it. Why do you need to program your mod this way? Or are you just doing it for fun?
My Blog - nav.education
In NAV you can export and import objects via files - well-known opportunity.
1. export to file
obj.RESET;
obj.SETRANGE(ID,55550);
obj.SETRANGE(Type,obj.Type::Codeunit);
IF obj.FIND('-') THEN BEGIN
obj.CALCFIELDS(obj."BLOB Reference");
obj."BLOB Reference".EXPORT('c:\a.obj');
END;
2. import from file
obj.RESET;
obj.SETRANGE(ID,55550);
obj.SETRANGE(Type,obj.Type::Codeunit);
IF obj.FIND('-') THEN BEGIN
obj."BLOB Reference".IMPORT('c:\a.obj');
obj.modify;
end;
You could be save and load dynamics you objects for execute some parent's functions for example...
I find the cloest way to represent OOP in Navision is to build table structures that closely represent objects and place as much code in the tables as possible that works with the data. This ensures that Code (methods) & Data (properties) are at least compiled into the same object. It's not idea...and in oder to copy or inherit from objects you have to copy one object into the other (basically copy & fork).
Also remember if you wanted to you can build your own recordsets and objects in memory using RecordRef objects and Temporary Tables.
Epimatic Corp.
http://www.epimatic.com
If you need OOP, you can program it in VC and use Automation to use it in NAV... 8)
MVP - Dynamics NAV
My BLOG
NAVERTICA a.s.
RIS Plus, LLC
MVP - Business Apps
I think Navsision is not OOP because it requires there is a common platform and executable base that places restrictions on what and how you can build your customizations. I've seen similar fully object oriented frameworks (like JBoss and some build on .Net) that require a lot of configuration and development time just to get simple things working.
As denster pointed out...OOP is a means to an end. In most cases clients care more about getting business functionality codified and running (within budget) then they do about the specifics like an OOP development environment.
Epimatic Corp.
http://www.epimatic.com
If you say, OO is not needed, I agree. You can do whatever you like with non-OO environments. If you say, it's only for design, I agree. But if you put those two together: if you have to create an (big) application, it's much easier when you have an OO overview of the system, to put it into OO code. (Long live UML! )
But, NAV is an existing application. Microsoft has to maintain simplicity and easy (read: fast) development. This is something OOP doesn't allow. Changing the design usually affects multiple layers in the class design, which you do not want. Therefore, we should be glad the system isn't OO-based! And let's hope MS keeps it this way .
... to give my two cents ... (or how do you say it ...)
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
Enough of the grumble
Any idea have a right to live. All your facts are known long ago.
So have you a propose?
and...and.. ERP systems are not meant to be simple
also Microsoft bought it over, they didn't develop it...
ERP Consultant (not just Navision) & Navision challenger
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog
I am making a "PrintToPDF" function now, and have been trying to make it work with any report, so I have experimented abit with using "Object" for polymorphism, but no luck so far.
Guess I'll need to make it a "CustomerToPDF" function instead.
OOP-mindset really sticks from school! Hard to let it go.
Eric Wauters
MVP - Microsoft Dynamics NAV
My blog