Home | Forums | Contact | Search | Syndication  
 
 [login] [create account]   Friday, November 29, 2024 
 
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!
 Architect Forums - SalesLogix Scripting & Customization
Forum to discuss writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
Forums RSS Feed


 Back to Forum List | Back to SalesLogix Scripting & Customization | New ThreadView:  Search:  
 Author  Thread: Managing Customizations
John Gundrum
Posts: 632
Top 10 forum poster: 632 posts
 
Managing CustomizationsYour last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 10 Apr 06 10:45 AM
fiogf49gjkf0d
This forum seemed to be the best place to post this.

We are slowly beginning to add customizations to our SLX 6.1 system. Its not the web version.

Is there a 'best practice' in migrating customizations between versions? Normally everything here is is Visual SourceSafe but there doesn't seem to be any kind of source control in Architect.

What I've done in the past is copy all the script out from a customized form, paste it into a text file, save it, check it into source safe. Then take the new form, copy all the script, paste into a new text file, save that, check into sourcesafe then use source safe to compare the two files.

One issue with this is form controls. Your only comparing the script - not the form and the controls contain therein.

Ideas, thoughts?

Thanks
John G.
[Reply][Quote]
Ray Villarica
Posts: 1
 
Re: Managing CustomizationsYour last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 11 Apr 06 12:12 AM
fiogf49gjkf0d
Hi John,

I have nothing to contribute with regard to best practices but I have a suggestion, what about using the bundler to to bundle your forms according to what ever grouping is necessary ie. by release, or by component etc. and storing the bundle in VSS?

I'm glad you raised this issue and look forward to seeing what others have discovered as to best practises in SLXdev version control, especially with regard to upgrades or service packs that threaten re-writes of customisations.

Ray.
[Reply][Quote]
Timmus Agersea
Posts: 328
 
Re: Managing CustomizationsYour last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 12 Apr 06 2:03 AM
fiogf49gjkf0d
John, I really dont like to discourage others from trying to find solutions but this is one area that I believe you are going to beat your head against the wall. Source control just does not work with SalesLogix customizations.

Many of of us have been begging SalesLogix for years to give us good diff and analysis tools to ease the pains of upgrades. Unfortunately there has been nothing offered.

Our approach is:
1. Identify plugins changed by an upgrade
2. Identify plugins within that set that have been customized (requires analysis)
3. For the list that requires analysis compare the stock product versions (how has the account detail changed between 6.1 and 6.2 for example)
4. decide whether we should add the SalesLogix changes to our custom plugin, ignore the SalesLogix changes, simply adopt the new SalesLogix plugin, or apply our customizations to the stock plugin.

It is very difficult to mitigate risk when it comes to SalesLogix upgrades. IMO your only option is painful analysis (manual) and thorough regression testing.

I dont recommend the effort as I see little reward, but if you want you can use Execute SQL in the administrator to get a text representation (mostly) of a form that you could paste into a text file.

Timmus
[Reply][Quote]
John Gundrum
Posts: 632
Top 10 forum poster: 632 posts
 
Re: Managing CustomizationsYour last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 12 Apr 06 9:51 AM
fiogf49gjkf0d
Timmus,

Thanks for the information. I guess I'll just have to document well and test, test, test.

John G.
[Reply][Quote]
Gregor F. Anton
Posts: 12
 
Re: Managing CustomizationsYour last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 23 May 06 3:00 AM

ventolin over the counter philippines

ventolin over the counter philippines redirect
fiogf49gjkf0d
There is one utlitiy that helps (a little). The compare function in Architect. (see below)

Plus some coding practices. For example when adding code to a SLX form, say the AXFormChange event, create a custom sub, ie. C_AXFormChange and call that sub from AXFormChange. That way your code is easy to read and makes upgrading a little easier. If creating a new event for an OOTB form then rename the even, ie. C_AXFormCreate. again to better understand whats custom and not.

Gregor Anton
www.antonsolutions.com
---
From the SalesLogix Compare PowerUser Utility
Technical Bulletin - email me at ganton@antonsolutions.com an I'll send you the zip file containing the word document.

Compare PowerUser Utility
SalesLogix v6.2 Architect has a way to compare scripts (or any plugins with obvious limitations)! This is a "PowerUser Utility" which means unsupported and as-is - you'll see the disclaimers when you use it.
What do you need to install?
First, you must have a "diff" or compare utility that accepts command line parameters installed. Then you must “install” the SalesLogix utility with a Registry value.

I'll use CSDiff for my example which is available FREE at http://www.componentsoftware.com/products/csdiff/?404;http://www.componentsoftware.com/products/csdiff/intro.htm.
Installing the Compare PowerUser Utility
Installing the utility is a simple addition to the Windows Registry. You may use the REG file embedded in this document or the details are shown below.
Please note this example and REG file assumes you will be using CSDiff – if you are using a different application, make sure to change the command line when you use the utility for the first time (the utility will then automatically update the Registry with the correct command line).

[HKEY_CURRENT_USER\Software\SalesLogix\Architect\ManagePlugins]
"ShowCompare"="1"
"CompareApp"="C:\\Program Files\\ComponentSoftware\\CSDiff\\CSDiff.exe /i /n [File1] [File2]"
Using the Compare PowerUser Utility
Open Architect to use the utility.

In Architect Plugin Manager you will now notice a "Compare" button (grayed out). When you select any two plugins and click (now active) Compare button, a dialog will popup.

The first time, you have to enter the command-line parameters to your utility (the attached Registry key includes the command-line for CSDiff). The command line parameters are whatever your tool of choice uses. Use [File1] and [File2] as the placeholders for the plugins that will be compared. Please note the first file found in the list will be File1, second will be File2 - so use Plugin Manager sorting to get in the order you want.

Then simply click Compare and your utility appears with the comparison of plugins.

---

Gregor Anton
www.antonsolutions.com
[Reply][Quote]
 Page 1 of 1 
  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!
 

 
 slxdeveloper.com is brought to you courtesy of Ryan Farley & Customer FX Corporation.
 This site, and all contents herein, are Copyright © 2024 Customer FX Corporation. The information and opinions expressed here are not endorsed by Sage Software.

code of conduct | Subscribe to the slxdeveloper.com Latest Article RSS feed
   
 
page cache (param): 11/29/2024 3:02:16 PM