RTC alternatives to NextControl property and ACTIVATE method

pippolomeo

hi, the topic title pretty much says it all: I have made a Form for the Classic interface which makes use of ACTIVATE() and NextControl; basically, they are needed because I need that, at an editbox OnAfterInput() (when user presses ENTER), the content of the editbox has to be used as input for another method, then the editbox has to be blanked, and the focus has to be set on the editbox itself again.

ACTIVATE() is used to update (i.e.: blank) the control, while NextControl is set to the same ID of the editbox in order to set the focus to the editbox itself again.

however, I have found out that unfortunately neither NextControl or ACTIVATE() are available in the RTC interface, so I'm stuck.

Do you have any alternate idea for this?

kine

There is no such a possibility now under RTC. Do not forget - RTC is about what to show, not how to show it... and because all is working differently, there are not triggers like OnActivate.

pippolomeo

thanks for your reply kine; I understand what your point is about, though I still think that it should be possible to set the focus anywhere in the page, as it is possible to do this in a standard web page, so there is no technical reason for not allowing this. also, although you are of course right saying that RTC is about showing things, it is also true that managing focus is something which should be available in any kind of GUI which is used to insert/edit data.

my problem is that I wanted to support the insertion of data by bar-code readers using keyboard emulation in batch mode: these readers usually separate each bar-code with an ENTER key, so what I need is basically a way to reset the focus to the editbox where the bar-codes are written each time a new bar-code is inserted; this is possible on the Classic GUI using the NextControl property and I really see no reason for which this could not be made under a web page too.

kine

pippolomeo wrote:

thanks for your reply kine; I understand what your point is about, though I still think that it should be possible to set the focus anywhere in the page, as it is possible to do this in a standard web page, so there is no technical reason for not allowing this. also, although you are of course right saying that RTC is about showing things, it is also true that managing focus is something which should be available in any kind of GUI which is used to insert/edit data.

my problem is that I wanted to support the insertion of data by bar-code readers using keyboard emulation in batch mode: these readers usually separate each bar-code with an ENTER key, so what I need is basically a way to reset the focus to the editbox where the bar-codes are written each time a new bar-code is inserted; this is possible on the Classic GUI using the NextControl property and I really see no reason for which this could not be made under a web page too.

1) RTC Page is not web page ;-)
2) Right now, there is no standard way how to manage that
3) You can use addin to create such a editbox, which will call your trigger and will keep the focus where it is. Creating addin is not so hard, just look at the blogs...

pippolomeo

thanks for your clarification kine, I will take a look at this addin stuuf; I'm a NAV newbie but not a coding newbie, so customizing a control should be exactly what I was looking for

freddy.dk

If your page has one enabled control (and only one) this will remain focus'ed when pressing ENTER (after validate is called)

Shaggs

I'm trying to do something similar to this. No matter what I try though, I cant get the customer control (using a windows textbox) to do what I need. It seems there is no way of preventing NAV from receiving the enter keystroke, and leaving the control.

Has anyone does this successfuly?

Rob_Hansen

Frankly, this is a crazy limitation. I appreciate what the RTC is and the benefits it offers, and I've been working with it, but it has some limitations that are just ridiculous. The ability to control tab orders and focus/activate triggers is a very basic requirement. While we may not use it often, there are those times (when developing barcoding solutions or mobile/handheld solutions) when it is critical. The fact that you now have to look at developing add-ins to TRY to recreate the functionality blows my mind.

A large part of NAV's success up to 2009 was the fact that it was a rapid development environment with full access to the application code and the ability to control ALMOST anything...in short, incredible flexibility. Seeing those benefits falling off with the RTC scares me. I look forward to a client asking me to develop this sort of functionality (requiring focus/activate control) and me having to tell them it will take a bunch of time as we need to develop add-ins to pull it off. That for something that would have taken a matter of minutes in the classic client...scary.

Don't get me wrong. I'm not just here to bash the RTC. BUT, there are some basic areas where it clearly is deficient and capabilities need to be added back sooner rather than later. While Navision 2.0 may have been lacking in a lot of functional capabilities, it was still ahead in terms of user interface control in a lot of ways. Again I say...scary.

jlandeen

I agree that clearly there are reasonable use cases for next and activate commands. Just like there are use cases for the Matrix box functionality that was not originally availble in the RTC (I haven't confirmed but I do believe this was added back in during SP1). Hopefully Microsoft will take this as another one of those "features" that should be incorporated into the next SP or next version of the product.

Thankfully there is always the good old classic client that can be implemented in the cases where a client absolutely needs that functionality (like barcoding or other simplified UI requirements).

kine

The main problem is the divided presentation logic and business logic. What you are trying is to connect the business logic to specific presentation logic but it is problem. RTC is done in a way that it is independent on the "rendering target". Thus words like "focus", "next control", "Position", "Size", "Color" etc. are out of scope, because you never know how the page will be rendered and how the controls will look like. It is big plus, but in other way it is big limitation. It is why the specialized cases like touch screens, mobile devices etc. should be handled in different way and it is on partners and ISVs to develop some additional things which will address this. With the webservices and addin possibilities it is not hard to do what you want, but yes, it needs something more than C/AL...

jlandeen

That is a valid point that this really does present an opportunity for new development models, partners and ISV's. I think with the 3 tier architecture it does make it a lot easier to integrate controls and other functionality built in an environment like Visual Studio where you can control just about everything under the sun. That works great for new development teams that have .NET capabilities....but I think it can be threat or a problem for partners and development shops that don't have those capabilities (but they do have all the NAV experience and know the application).

I guess I just see this as a case of functionality that was useful being removed so that we could have the new look and feel as well as the 3 tier architecture. Hopefully there's more than enough positives of the new RTC to make up for the loss of something like this but clearly it's up for debate!