"]When we build NAV 1.0 back in 1994 it was me who decided not to do unicode and stay with OEM like
I have a voodoo doll with your name on it right here
we decided that it would not be worth doing since we would have needed to drop other important V7 features instead.
The rationale is invalid. You are implementing more features -> more work for developers. At the same time you're making life miserable for developers -> fewer developers and less resources -> more expensive solutions -> fewer customers.
To sum up: more features -> fewer customers. That's probably not what you're aiming for.
You are alienating developers by consistently undermining and weakening the development environment compared to any other development tool in existence. Considering how faithful NAV developers have proved to be, this is inexcusable.
Oh, and I should add that the majority of existing tools cannot be converted to using pages as we do not have access to the developer environment from a page... (which we have from a form).
"]When we build NAV 1.0 back in 1994 it was me who decided not to do unicode and stay with OEM like - so I am the right person to blame for not being able to support unicode and classic forms in V7
The world was a little different in 1994 and probably the customers/partners targeted by NAV were also different than now.
Regards,Alain Krikilion No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
Oh, and I should add that the majority of existing tools cannot be converted to using pages as we do not have access to the developer environment from a page... (which we have from a form).
You can access the Development environment from pages for what I know. I have not experimented with it but at NavTechDays 2011 Michael showed that you can make a page on the object table and start the editor from there using Powershell.
My guess is that once these opportunities are there, there will be a bunch of new downloads on Mibuso with new tools. Also I expect tools developers like OMA to use these fetures (I expect, I don't know).
The idea behind these features is to enable partners to create their own devtools in pages or purchase commercial tools like OMA.
Comments
The rationale is invalid. You are implementing more features -> more work for developers. At the same time you're making life miserable for developers -> fewer developers and less resources -> more expensive solutions -> fewer customers.
To sum up: more features -> fewer customers. That's probably not what you're aiming for.
You are alienating developers by consistently undermining and weakening the development environment compared to any other development tool in existence. Considering how faithful NAV developers have proved to be, this is inexcusable.
Oh, and I should add that the majority of existing tools cannot be converted to using pages as we do not have access to the developer environment from a page... (which we have from a form).
Senior NAV Developer
Elbek & Vejrup
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
You can access the Development environment from pages for what I know. I have not experimented with it but at NavTechDays 2011 Michael showed that you can make a page on the object table and start the editor from there using Powershell.
My guess is that once these opportunities are there, there will be a bunch of new downloads on Mibuso with new tools. Also I expect tools developers like OMA to use these fetures (I expect, I don't know).
The idea behind these features is to enable partners to create their own devtools in pages or purchase commercial tools like OMA.