7/8/2025 2:34:22 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 writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
|
|
|
|
Wscript Error
Posted: 11 Feb 08 10:59 AM
|
dim WshShell
set WshShell = CreateObject("WScript.Shell")
WScript.Sleep 500
The third line gives me an error "Variable not defined"
Please Help.. |
|
|
|
Re: Wscript Error
Posted: 11 Feb 08 11:26 AM
|
WScript is not a defined object in SLX VBScript. Why the need to sleep anyway? Isn't SLX slow enough for you already  |
|
|
|
Re: Wscript Error
Posted: 11 Feb 08 11:35 AM
|
Its true..it is slow already...but my scenario is this.. i am inserting a new row onto a table and in the next line i am updating one column of the newly inserted row. there is no enough time between the new row creation and the column update. so when i go for an update, the row is not available... i guess u got teh picture... if i do a debug its working fine...
is there anyother way than making it to sleep... |
|
|
|
Re: Wscript Error
Posted: 11 Feb 08 1:14 PM
|
I can't say I have *ever* had the problem you describe of inserting a row and then updating a field on it and have it not be there......ever. The problem doesn't make much sense to me. Maybe post some of the code for us to look at - I am surprised that you're seeing this behavior.
Anyway, if you really wanted to wait, you could add a timer to the form, do the insert and then enable the timer (which has the interval you want set) and then on the OnTimer event do the update - but again this is to solve a problem that you should not be having in the first place (which is what I think you should focus on)
-Ryan |
|
|
|
Re: Wscript Error
Posted: 11 Feb 08 1:38 PM
|
Thanks Ryan..but i actually solved the issue by writing the insert and update all in one line...
this is the situation...
InsertRow() 'inserts a new row with columns a b c
updaterow() 'updates the above row with column d
updaterow() could have been done when insertrow was being done but for some reason i did it in two different steps... but the point is when the updaterow() method is called..the row is not available for updation..but if i put a messagebox or do the debug between these methods...it works...
strange but it is happening... 
now i resolved the issue by making it a one step...ie both insert and update in one single method..
|
|
|
|
Re: Wscript Error
Posted: 12 Feb 08 1:21 AM
|
I don't understand why you are inserting a row and then updating it. If you have the data for the update, why not use it in the insert?
BTW, this could cause a problem with sync. |
|
|
|
Re: Wscript Error
Posted: 21 Jan 09 4:55 PM
|
| I need a sleep function to pause for Windows messages on a progress bar.....anything clever out there? |
|
|
|
Re: Wscript Error
Posted: 21 Jan 09 5:16 PM
|
Originally posted by RJ Samp
I need a sleep function to pause for Windows messages on a progress bar.....anything clever out there? |
|
If you just need to pause to let something like a progressbar, or other controls, to update (receive and process their windows messages), then you can use the built in
Application.BasicFunctions.ProcessWindowsMessages
If you need an actual wait time, then you can use a timer control (if on a form). |
|
|
|
Re: Wscript Error
Posted: 22 Jan 09 8:39 AM
|
Thanks!
And of course I found the new SLX Progress Bar Control this morning, got it running and it looks great! No need for a seperate IE Progress Bar... |
|
|
|
Re: Wscript Error
Posted: 03 Nov 09 6:58 AM
|
Originally posted by Ryan Farley
If you just need to pause to let something like a progressbar, or other controls, to update (receive and process their windows messages), then you can use the built in
Application.BasicFunctions.ProcessWindowsMessages
If you need an actual wait time, then you can use a timer control (if on a form). |
|
What if you are using a script?
I am using two scheduled server tasks to run SLX scripts via .NET. I am having one script look for the "active" status of the other by checking a status flag potentially set by the latter process. I would like for the check to be "periodic" so the goal is to have it wait for a few seconds, then check again (rather than continuously check it, taking up 100% CPU).
I thought about writing a small .NET dll just to allow for the Windows script to be used inside VBScript, but that seems a little excessive for the "return on investment". Maybe there's another alternative or approach, I just haven't thought of one.
Why is WScript not available when Windows Shell is? Isn't Windows Shell part of the WScript object? |
|
|
|
Re: Wscript Error
Posted: 03 Nov 09 7:29 AM
|
Chris:
I think there may be better approaches at doing this. Why do you need to check every few seconds? Why running SLX Scripts?
If you are checking for DB value changes, why don't you rely on a DB Trigger, Knowledge Sync or even a Custom Windows Service?
If you have remotes and need to synchronize any actions you take after the fact, you would make the changes via the OLEDB Provider.
For instance, you could have a Trigger on the table, and if it finds the conditions you are looking for, it could instantiate a .NET CLR Object that contains your business logic and connects to SLX via the OLEDB Provider.
Or, you could use KnowledgeSync, and similarly execute a script that runs connect the OLEDB Provider.
Or, a Custom Windows service built on .Net, and as stated, would also run connect the OLEDB Provider.
|
|
|
|
Re: Wscript Error
Posted: 03 Nov 09 9:04 AM
|
Originally posted by Raul A. Chavez
Chris:
I think there may be better approaches at doing this. Why do you need to check every few seconds? Why running SLX Scripts?
If you are checking for DB value changes, why don't you rely on a DB Trigger, Knowledge Sync or even a Custom Windows Service?
If you have remotes and need to synchronize any actions you take after the fact, you would make the changes via the OLEDB Provider.
For instance, you could have a Trigger on the table, and if it finds the conditions you are looking for, it could instantiate a .NET CLR Object that contains your business logic and connects to SLX via the OLEDB Provider.
Or, you could use KnowledgeSync, and similarly execute a script that runs connect the OLEDB Provider.
Or, a Custom Windows service built on .Net, and as stated, would also run connect the OLEDB Provider.
|
|
Hey Raul,
We are doing imports into Saleslogix from external tables. The SLX scripts are "batch" versions of specific custom forms we currently use to process accounts, contacts, and enrollments. We've done this in order to utilize the underlying custom routines used in our SLX database to produce all of the records normally created during a typical "interactive" SLX session; in so doing, we prevent "reinvention of the wheel" and keep things consistent. This (along with the "less than straightforward" code for our business logic) is the reason why I chose not to rewrite all the business logic within .NET; instead I decided to write a .NET dll to use the Saleslogix Application Object to execute the aforementioned SLX scripts. Each of the scripts runs in a Windows scheduled task using the .NET dll.
Our approach, basically, is to run (within the Windows scheduler) the aforementioned SLX scripts via a .NET dll that uses an instance of the SLX Client.
This approach is already in production and works as designed. The two (2) issues I am dealing with are:
(1) How to launch (and stop) the SLX Client. Currently, I have an instance of the SLX Client up and running at all times. It's not the way I would have liked, but it works for the short term. I am currently investigating ways to auto-launch and stop the client.
(2) Collision of global variables. This is because I am using the same (active) SLX Client for both processes. This problem would be resolved if I were able to accomplish (1). Because of the common instance of the SLX Client, I want one process to run only if the other one is not active. Then I can "clear" the global variables before starting the current process. I was thinking about using WScript.Sleep to get one process to wait for the other; hence, my original inquiry concerning availability of the WScript object within VBScript.
Again, problem (2) would be irrelevant if (1) were resolved. |
|
|
|
Re: Wscript Error
Posted: 04 Nov 09 7:59 AM
|
Originally posted by Chris Fleetwood
...(2) Collision of global variables. This is because I am using the same (active) SLX Client for both processes. This problem would be resolved if I were able to accomplish (1). Because of the common instance of the SLX Client, I want one process to run only if the other one is not active. Then I can "clear" the global variables before starting the current process. I was thinking about using WScript.Sleep to get one process to wait for the other; hence, my original inquiry concerning availability of the WScript object within VBScript.
Again, problem (2) would be irrelevant if (1) were resolved. |
|
It seems to me the issue is the global variables.
Can you make properties of the dll available to the scripts instead of depending on global variables? |
|
|
|
Re: Wscript Error
Posted: 04 Nov 09 11:08 AM
|
Originally posted by Chris Fleetwood
(1) How to launch (and stop) the SLX Client. Currently, I have an instance of the SLX Client up and running at all times. It's not the way I would have liked, but it works for the short term. I am currently investigating ways to auto-launch and stop the client.
(2) Collision of global variables. This is because I am using the same (active) SLX Client for both processes. This problem would be resolved if I were able to accomplish (1). Because of the common instance of the SLX Client, I want one process to run only if the other one is not active. Then I can "clear" the global variables before starting the current process. I was thinking about using WScript.Sleep to get one process to wait for the other; hence, my original inquiry concerning availability of the WScript object within VBScript.
Again, problem (2) would be irrelevant if (1) were resolved. |
|
It has been quite a few years, but I have had to deal with #1 many times (in order to use the old Automation Interface). That being said, there are flags that can be used to Invoke the SLX Client with credentials to "auto-login" , but you could also configure an account with Windows Authentication, so that would take care of the auto-login.
Then, in order to terminate it you may call "Application.Quit" within your script.
There are many ways to monitor if a process is running, so this should give you some hints as to how to accomplish #1.
Here are the command lines for SLX Client:
/N: The user name (first field in the Log on dialog box).
/P: The user password (second field in the Log on dialog box).
/B: The database connection (the third field in the Log on dialog box). To use this parameter, you must also specify /N.
/BYPASSNTLOGIN: Disables Windows Authentication and opens the Log on dialog box. For example, if Windows Authentication is in use and you need to log on to the Sage SalesLogix Client as Admin, use this switch.
/NOSPLASH: Removes the splash screen.
E.g.: "C:\Program Files\SalesLogix\SalesLogix.exe" /B SalesLogix /N jdoe /P mypwd
|
|
|
|
Re: Wscript Error
Posted: 19 Nov 09 12:24 PM
|
Originally posted by Raul A. Chavez
It has been quite a few years, but I have had to deal with #1 many times (in order to use the old Automation Interface). That being said, there are flags that can be used to Invoke the SLX Client with credentials to "auto-login" , but you could also configure an account with Windows Authentication, so that would take care of the auto-login.
Then, in order to terminate it you may call "Application.Quit" within your script.
There are many ways to monitor if a process is running, so this should give you some hints as to how to accomplish #1.
Here are the command lines for SLX Client:
/N: The user name (first field in the Log on dialog box).
/P: The user password (second field in the Log on dialog box).
/B: The database connection (the third field in the Log on dialog box). To use this parameter, you must also specify /N.
/BYPASSNTLOGIN: Disables Windows Authentication and opens the Log on dialog box. For example, if Windows Authentication is in use and you need to log on to the Sage SalesLogix Client as Admin, use this switch.
/NOSPLASH: Removes the splash screen.
E.g.: "C:\Program Files\SalesLogix\SalesLogix.exe" /B SalesLogix /N jdoe /P mypwd
|
|
Thanks for your suggestions, Raul - they've been a great help.
I was able to use the command line approach to automatically start the SLX Client. I used a .NET dll to invoke the command using Windows Shell and then captured the process ID as the output from the Shell command. Then I used the same .dll to issue the "Kill" command within Shell using the aforementioned process ID.
I don't know why I didn't think of the Application.Quit command. I'll keep that in mind. That may be a more "graceful" way to exit SLX then using the "Kill" command.
Thanks again!
Chris |
|
|
|
Re: Wscript Error
Posted: 19 Nov 09 12:46 PM
|
Originally posted by Trent Haynes
It seems to me the issue is the global variables.
Can you make properties of the dll available to the scripts instead of depending on global variables? |
|
Hey Trent,
The sole purpose of the DLL is to invoke the scripts. The scripts existed (in production) prior to the DLL and are each responsible for setting their own global variables, to modify the behavior of certain supporting routines used by both scripts. As long as they are running separately (meaning only one is active at a time), there is no issue with the current configuration.
I am now having each job start its own instance of the SLX Client before processing and terminate that client instance afterwards. That has resolved the "global variables" issue imposed by having a common instance of the client.
The remaining issue is how to have more than one SLX Client instance running at the same time and having each script "detect" its specific application instance and execute in that runtime exclusively (I know this involves "thread processing" but I don't know a lot about that subject, or a way to implement such with the SLX Client, if indeed it is possible). For now, I am getting around this issue by (1) Scheduling the two jobs with enough buffer time between them so that they are unlikely to start simultaneously and (2) Adding code to check a process flag that indicates if it has been "touched" by an active process and not yet "reset". These two (2) approaches together will work for the time being.
Chris |
|
|
|
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!
|
|
|
|
|
|
|
|