Current filter:
                                You should refresh the page.
                                Show all comments
                                • Robert Fuchs 03.13.2013

                                  Hi guys,

                                  would be nice if you could implement this after almost 5 years!

                                  Thanks in advance.

                                • Ralph Rutschmann 03.13.2013

                                  Hi Robert,

                                  I don't think that it will be implemented, because too few customers demand it and already an example or workaround is how you can build it yourself.

                                  Simply use Visual Studio. XAF is extensible in every conceivable way...;-)

                                  I don't really expect another answer, do you? But I hope we're get surprised!

                                  Best regards, Ralph

                                • Marco Kummer 03.14.2013

                                  Guys,

                                  I agree with Ralph. No real answer to be expected. If you want to know my opinion: DX is letting XAF die of negligence. This has started to disappoint me to a great degree. Since DX started working intensely on the first release of DXTreme, the progress in the XAF department has degraded to nearly zero. I led a discussion about how important it would be to add mobile templates to XAF ASP.NET in today's mobile world, but DX's answer was basically: It's too complex, just juse DXTreme for the mobile part. Yeah right, as if DXTreme would support stuff like conditional formatting out of the box... we're back to coding everything by hand again.My argument about how XAF provides really EVERYTHING we need to add mobile support relatively "easy", was unheard.

                                  Also check out our discussion on S19224 (several browser tabs in XAF). 5 year old request and totally important nowadays. Nothing seems to be done about that either.

                                  If I don't get to see a promising XAF roadmap anytime soon, I will not renew my subscription for the first year. It's better to write my own business framework in ASP.NET MVC using EF. Then at least I can be somewhat sure that support will continue into the future.

                                  Best regards, Marco

                                • Dennis (DevExpress Support) 03.14.2013

                                  @Robert: Ralph has a good point here. Yes, it would be nice to have this feature out-of-the-box, but sometimes it is not possible to find resources for such "nice to have" things when there are other requests, which cannot be easily implemented or worked around by customers.
                                  Here nothing prevents you from adding this functionality yourself, exactly like you would do without XAF. In case of RichEditControl it seems to be reasonable also because you may not like the default set of toolbars and options of the default editor or quite likely would want to customize it in a special way. RichEditControl provides rich design-time experience. What can be easier than designing a user control in Visual Studio for your exact business scenario and enabling only required options? Then, it is a matter of seconds to create a PropertyEditor class where your custom user control will be instantiated. Other custom features like 'mail merge' can be added in the same manner as you would do in a regular non-XAF WinForms application.

                                  @Marco:
                                  While I highly appreciate your initiative about mobile templates for XAF Web UI, it is surely heard, but we are somewhat sceptical about this, because it may not meet needs of users accustomed to popular mobile experiences. As you understand, the reason is simple: the experience from a native or hybrid JavaScript-based app will be extremely different from the same app built using ASP.NET server-side controls even adjusted to work on the large screen. Also, adjusting controls and templates does not seem to be the last step here, but changing the application flow would be most likely required (like reworking or removing popup windows). I am not even talking that the current XAF Web UI architecture is not good for mobile apps. Finally, having a framework (DXTREME) that was primary designed for creating mobile apps further diminishes the appeal of this mobile template idea. So, as you can see, we have a valid reason for not pursuing this idea, at least until someone creates these custom templates on his/her own and shares his/her clients' experience.
                                  As for opening multiple browser tabs, I do not have much to say on this, because we have not worked out this limitation of the stateful Web UI nature.

                                • Marco Kummer 03.14.2013

                                  Dennis, just one last note about your comment. I totally understand and agree with your arguments from a technical standpoint. Yes, mobile templates with the current ASP.NET XAF code base are difficult to implement, especially for smart phones because of frequent popups. But above all the technical issues, there's a strategic layer on top that DX seems to be forgetting about: XAF is advertised as an **express business app framework** So if business apps nowadays require access from mobile devices, then that's just a reality that needs to be faced, REGARDLESS of technical difficulties. How many times did you guys have to introdue breaking changes in XAF to follow a better design? Why should it be any different with mobile support, multiple browser windows and all those other usability improvement requests waiting to be implemented? Using DXTreme for mobile support is one approach, but it takes away the "express" from XAF and promotes code duplication. I also don't think it's your customers' job to produce mobile templates and then share them along with their experiences. If anyone's willing to do so, that's of course great. But we're paying our subscriptions so that DX holds up to its promise of a business app framework that meets business people's actual needs. And nowadays those needs include mobile access without any doubt. So either XAF continues to be a modern app framework or not - This strategic decision is entirely up to DX.

                                  As for the technical layer: I already made a few suggestions in another thread : Introduce new list variants like Customer_DetailView_SmartPhone and Customer_ListView_SmartPhone. I also don't see any problem with using server side events (AJAX). Who says they should not be used? All modern MVC frameworks use them regularly (Ruby, ASP.NET MVC...) And also remember that end customers don't care about HOW something is implemented. Sadly for us they'll never appreciate the beauty of a clean MVC design or local javascript code. They only care about getting the job done. So if an AJAX call behind a button takes 0.5 seconds for a server rountrip instead of 0.1 second for a local javascript call... end users really don't care.

                                  I don't want to steal any more of your time, I know you have more pressing issues :-) But I'm getting very frustrated about the lack of progress and the uncertainty in the XAF department. It's driving me crazy with so many customers and so much code base. I believe that the management of DX owes us a clear statement on where XAF is going in the next few years. After all I'm not the only one who's concerned here.

                                • Dennis (DevExpress Support) 03.15.2013

                                  @Marco:
                                  Thanks again for your time and input. I highly appreciate it and I am glad to have a chance working with you. I fully understand your business requirements and understand your concerns as a customer. The reality however, is that the framework was never meant to do certain things it's being asked to do. Originally, we designed it to rapidly build desktop Windows and Web apps, mainly data-centric line-of-business apps. We believe we achieved this goal and the framework does its job quite well. We did not plan to cover mobile scenarios at the time our framework was designed. It would be now be valuable to have support for this scenarios too, but trying to be the "be all and end all" solution is next to impossible here, and above I already shared some of the technical considerations with you. I would take special note that if you don't use XAF for development, you will also need to address the same issues like code duplication, learning JavaScript or other platforms, etc., simply because the new mobile scenarios bring completely new tools, approaches, etc.
                                  As for XAF, we will continue making it stronger for the scenarios it was primarily designed for with great feedback from our customers. No one has stated that they no longer need desktop software for business.
                                  Having said that, I would like to finish with this off topic at present. If you have any questions on this, feel free to email us at management@devexpress.com.

                                • Marco Kummer 03.16.2013

                                  Dennis thanks for taking the time for this clear statement on the "future" of XAF.

                                  I suggest you guys take customer polls on the roadmap of XAF (big features that have been requested). That would probably yield the most objective view of what your XAF customers really need and expect of the product. The issue voting here in the helpdesk system is probably too detailed to derive a clear roadmap from it. This suggestion of mine is of course assuming that DX's focus is to take XAF in the direction that customers want it to go in the first place.

                                  And with that I'm also finishing this topic.

                                • Dennis (DevExpress Support) 03.18.2013

                                  Marco, thank you for the great feedback too!

                                • Chris Royle (LOB) 09.23.2014

                                  Back to the original thread. Let me just say that I'd also like the rich editor to be an officially supported property editor, rather than an "example".

                                • Jascha 09.23.2014

                                  I agree with Chris, this feels like it should be an included editor and from what I can see, not one you could credibly dismiss on the grounds of development time.

                                • Damir Matijevic 09.24.2014

                                  +1 I agree, guys

                                2 Solutions

                                Creation Date Importance Sort by
                                Hello,

                                We included the WinForms Spreadsheet and ASP.NET WebForms RTF editors in our Office Module in v19.1. To make sure that our future implementation meets your business requirements, we would greatly appreciate it if you test our early access preview version and/or answer our questions from the T721878: Office Module Enhancements for WinForms and ASP.NET WebForms - Early Access Preview v19.1 article

                                Thank you for your time and cooperation,
                                Andrey

                                I removed this original message as it wasn't intended to be a solution. See my suggested solution below in the discussion thread.

                                Show all comments
                                • David Shannon 03.14.2013

                                  This conversation has sort of drifted off the original point, which was implementation of a property editor based on the XtraRichEdit control. I still think that is needed, because the workaround is difficult and limited.

                                  Specifically, if you have more than one rich text property in a detail view, it is not easy to manage the rich edit menu. Creating a user control with the property editor and menu lumped together does work, but then if you have 2 or 3 of those on a detail view you have 2 or 3 menus taking up space.

                                • Dennis (DevExpress Support) 03.14.2013

                                  @David:
                                  Thanks for your feedback. It is possible to merge those menus, and the example contains some code for this. After all, you would face the same problem in the same scenario without using XAF, and this scenario is solvable in the same way you would do it in a non-XAF application.

                                • Marco Kummer 03.14.2013

                                  @David: Yes, I agree the conversation has drifted. Sorry about that. But ever since DX removed the general forums, there's no other place to discuss such things. In fac, DX encourages the use of this platform for general discussions. By the way, I do have your problem solved somewhere.... let me look up my source and maybe I can throw together an example.

                                • Marco Kummer 03.14.2013

                                  For anyone interested: I already went down this road once and tried to create a fully merging ribbon PropertyEditor using XtraRichEdit. I followed all the examples carefully and still kept running into strange issues where ribbons didn't merge correctly. Most problems occured when two RichEdits needed to be displayed side by side (not on separate tabs). I then came up with an different approach to the problem: I implemented a PropertyEditor using XtraRichEdit with normal (embedded) toolbars that expose only the most common formatting functions. This works great and is very stable in all scenarios. For advanced editing functions, I simply added a toolbar button which would bring up a modal full screen version of XtraRichEdit including ribbons. In my opinion this implementation has a number of advantages:

                                  - Most common formatting functions are right at hand above the editor (less mouse mileage)
                                  - Users are more familiar with this kind of toolbar-editor from websites
                                  - Rarely used functions are hidden in the full screen version, causing less distraction
                                  - You can have as many side-by-side editors as you wish, and work stable.
                                  - If needed, all advanced functions are still there
                                  - The full screen version allows end user to focus on the task at hand (writing his text) and provides more screen estate while composing his letter or whatever.

                                  If anyone's interested, I'm attaching a full sample to this post. Remember to click on the "full screen" button in one of the editors to get the full functionality (if any ribbons are missing in the full screen version, you can add them easily. Just consult the online documentation of XtraRichEdit)

                                • David Shannon 03.14.2013

                                  @Dennis: The notes on the sample say it does not work for multiple editors, so I didn't know there was code in there to handle that situation. I'll take a look at it the next time I hit this issue. Are you aware of any DX examples (outside of XAF) that show the use of multiple rich edit controls on the same tab of a form with merging menus?

                                  @Marco: Thanks for putting up the sample. I'll take a look at it the next time this comes up. In the past I had an app that had four rich edit fields on a tab, arranged in a 2x2 square. Unfortunately, there wasn't much room left for toolbars. That's why I was hoping for this to be implemented.

                                • Apostolis Bekiaris (DevExpress) 03.15.2013

                                  Looks interesting Marco thanks for sharing maybe we can add it in eXpand as well

                                • Dennis (DevExpress Support) 03.16.2013

                                  @David:
                                  I do not have a ready code example for you right away, but our XtraRichEdit team will be glad to help you solve this challenge. Just log a new ticket via the Support Center for the XtraRichEdit product: http://www.devexpress.com/Support/Center/Question/Create

                                • Marco Kummer 03.16.2013

                                  @Tolis: Feel free to use my idea and/or source in eXpand. It's great to see when external ideas and inputs appreciated and taken into consideration. That's not at all taken for granted these days ;-) Best regards, Marco

                                • Apostolis Bekiaris (DevExpress) 03.25.2013

                                  Thanks again Marco your propertyeditor is included in eXpand v12.2.7.3

                                • Andrey K (DevExpress Support) 02.22.2018

                                  Hello,

                                  We are going to integrate Rich Text Editor and will be very pleased if you share your scenarios and thoughts in the scope of this ticket: T608185: WinForms Rich Text Editor integration considerations

                                  Thanks,
                                  Andrey

                                • Andrey K (DevExpress Support) 03.28.2018

                                  Hello,

                                  We created a first version of OfficeWindowsFormsModule and RichEditPropertyEditor based on your feedback. If you want to test this feature with your real world applications on a virtual machine (or another suitable test environment) prior to the official release, download the v18.1 preview build here: DevExpress XAF v18.1 Preview installer

                                  See T608185: WinForms Rich Text Editor Module - v18.1 Preview for more details.

                                  Thanks,
                                  Andrey

                                • Andrey K (DevExpress Support) 05.21.2018
                                  We published Office Module in 18.1 and now you can refer to its documentation: Office Module Overview 

                                  Thanks,
                                  Andrey