11/22/2024 2:56:40 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss the use of .NET Extensions in SalesLogix version 7 and higher. View the code of conduct for posting guidelines.
|
|
|
|
New name for ".NET Forms" in v7
Posted: 22 May 06 2:37 PM
|
cialis generico in farmacia esiste acquistare cialis in farmacia senza ricetta tfswhisperer.com fiogf49gjkf0d .NET Forms for SLX v7 will be renamed to more accurately describe the feature. The new name will be....(drum roll please)...
.NET Extensions
Much better.  I'll be renaming the appropriate areas of this site to match. |
|
|
| |
|
Re: New name for ".NET Forms" in v7
Posted: 23 May 06 12:59 PM
|
fiogf49gjkf0d In case anyone is wondering why the name change, the answer is that currently the only known way to add a data view to a MainView is to attach a managed UserControl to an AXForm using Win32 calls, and then the AXForms data-binding API is not fully exposed. This won't be addressed in the 7.0 version timeframe. There are simple workarounds to make it work (i.e. propogate the hosting AXForm's OnChange event, et al, using VBScript, use the ISlxApplication object to obtain the connection string, generate datasets or otherwise manually code up per-field ADO.NET calls, etc.), but they are a little kludgy, enough to make ".NET Forms" an unsuitable name for the new feature. |
|
|
|
Re: New name for ".NET Forms" in v7
Posted: 23 May 06 6:34 PM
|
fiogf49gjkf0d For me it is more than just that. Embedding .NET things in SLX is no different than before. However, the name ".NET Forms" implies that it is a forms based solution. It isn't (not that you were saying it is or anything). It is simply a way to extend SLX using .NET, nothing more than that really. It provides the glue to host the .NET stuff in SLX, get it out to the desktops, etc. You still do what you want in .NET just as before, only now you don't need to write your own launch code to tie it in and do your own AppDomain etc. And you don't have to distribute an install and get updates out with every change. You don't even need to get the .NET Framework on the desktops. The best part is that you can deliver a .NET solution to *any* v7 install and it will just work. That is awesome.
So .NET Extensions just fits soooo much better.
A great change - and I'm glad they listened  |
|
|
|
Re: New name for ".NET Forms" in v7
Posted: 23 May 06 11:13 PM
|
albuterol otc alternative albuterol otc walgreens fiogf49gjkf0d Agreed, thank you for correcting me. Someday I'll learn to put a positive (and, as such, more accurate) spin on things I greatly appreciate. Somehow I tend to see the glass as 1/4 empty rather than 3/4 full. |
|
|
|
Re: New name for ".NET Forms" in v7
Posted: 12 Jun 06 4:13 PM
|
fiogf49gjkf0d I wanted to make this point since I apparently forgot it. Ryan mentioned in another thread that as long as SharpDevelop compiles to version 2.0 it'll work. This means all of your ".NET Extensions" have to be compiled as 2.0? If distribution of the framework is taken care of and all versions of the framework are installed separately, which version is it targeting? My guess would be version 2 only but I know there are a lot of people still stuck on previous versions for whatever reason that may influence getting other versions of the framework installed. I would hope that if this were the case that there would be a way of specifying a version to target instead of having to load multiple frameworks onto each client machine. |
|
|
|
Re: New name for ".NET Forms" in v7
Posted: 12 Jun 06 4:25 PM
|
drug coupons free discount prescription card online fiogf49gjkf0d .NET Extensions will target .NET 2.0 only. The SalesLogix installer will install the .NET 2.0 Framework as a standard part of the installation routine for machines where .NET 2.0 is not present. That is just awesome. So, you can rest assured that .NET 2.0 will exist on every machine where SLX is installed  |
|
|
|
Re: New name for ".NET Forms" in v7
Posted: 13 Jun 06 11:26 AM
|
fiogf49gjkf0d Hey Jon - Can you educate me on why the WinForm must be represented as a UserControl in order to have teh WinForm/UserControl overlay the AXForm? I thought we were able to overlay a WinForm itself and did not have to turn the WinForm into a UserControl. It's probably just that I'm not up on the internals of WinForms, so apprecaite it if you can give me the scoop.
|
|
|
|
Re: New name for ".NET Forms" in v7
Posted: 13 Jun 06 11:37 AM
|
naltrexone buy naltrexone buy uk fiogf49gjkf0d You can overlay an entire WinForm on an AXForm in SLX. However, there's other things to deal with if you use a WinForm to do this. A WinForm, even while embedded on some other form, still responds to windows events. Things like loosing focus (and regaining it), system control actions, such as closing if the user hits ALT+F4, minimizing, etc, not to mention the extra overhead that a window brings (when compared to a control). These are not behaviors you'd expect from controls on a form. Using a usercontrol there is far less to worry about. Your .NET code really is a "formless" solution for this. You simply instanciate an object of your user control and the set it's parent, no overhead of loading a form.
Make sense? |
|
|
|
Re: New name for ".NET Forms" in v7
Posted: 13 Jun 06 3:31 PM
|
fiogf49gjkf0d Originally posted by Todd Hardin
Hey Jon - Can you educate me on why the WinForm must be represented as a UserControl in order to have teh WinForm/UserControl overlay the AXForm? I thought we were able to overlay a WinForm itself and did not have to turn the WinForm into a UserControl. It's probably just that I'm not up on the internals of WinForms, so apprecaite it if you can give me the scoop. |
|
What Ryan said.
The idea here is that a UserControl in .NET expects a parent container window. "Form" is, in my opinion, bad nomenclature on Microsoft's part to describe a wrapper of a Win32 standalone window (i.e. one that has a titlebar and can be moved around the screen). Fortunately, I believe .NET can treat System.Windows.Forms.Form implementations as UserControls, too, using some unusual techniques, but I prefer to implement UserControls and then if I need it in a window I just wrap the UserControl, even if just to stick with the design inferences of the Framework. The sample Account Detail form works in this way--the form is actually in a System.Windows.Forms.UserControl but the modal view is the same UserControl in a System.Windows.Forms.Form wrapper.
As you probably know, the same is true of AXForms being fundamentally UserControl equivalents. They are not "Forms" like VB6 or VB.NET sees the "Form" nomenclature. SLX wraps the Active Form views with a tab or other place on the Main View, or with a window in the case of a Manage View. Notice, for instance, that if you attempt to resize a Manage View programmatically at runtime it will either do nothing or simply add whitespace, revealing scrollbars; the window itself doesn't adjust at runtime when changing the AXForm dimensions because AXForm isn't a standalone window. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|