Sage 100

Janna,

The Tablacus Script Control 64-bit is an interesting platform that is an alternative to the Windows Scripting Host (WSH) we use today. It could be what we all need to use when future versions of Windows start to deprecate then eventually retire VBScript. I haven't tried it out myself yet though.

Assuming the "is taking longer" message is the same as was what WSH would tell you, here are 3 things you can potentially do:

1. Make sure the script is designed to run as efficiently as possible. For example, I see PreTotals scripts with Do Until/While Loops that scan thru the Lines but don't have an "Exit Do" line when the condition it's looking for is met, meaning it ends up scanning all the lines. Also depending on the purpose of the script, there might be a faster way to find the drop ship line (such as using SetBrowseFilter before the MoveNext OR using GetResultSets.where you can pass a condition for a DropShip=Y)
   
   
2. After your script verifies a UI is present, show a ProgressBar every so often. This solves this "is taking longer" msg the majority of the time. However I'm not sure a UI is detected when ScanForce creates the order.
   
   
3. By default the WSH allows 10 second timeout before showing you that msg but you can add for example ScriptTimeout=60000 to the server's SOTA.INI in the [Config] section. Now you get a 60 second timeout. The user would need to close out of Sage and restart it for it take effect.

Alnoor, so you think it's the VB script that's creating the Tablacus time out error?  I'm in the process of having the script look for a header field first to eliminate the loop through if a header field is no.  Will look at your other suggestions as well.

Janna,

The Tablacus Script Control 64-bit is an interesting platform that is an alternative to the Windows Scripting Host (WSH) we use today. It could be what we all need to use when future versions of Windows start to deprecate then eventually retire VBScript. I haven't tried it out myself yet though.

Assuming the "is taking longer" message is the same as was what WSH would tell you, here are 3 things you can potentially do:

1. Make sure the script is designed to run as efficiently as possible. For example, I see PreTotals scripts with Do Until/While Loops that scan thru the Lines but don't have an "Exit Do" line when the condition it's looking for is met, meaning it ends up scanning all the lines. Also depending on the purpose of the script, there might be a faster way to find the drop ship line (such as using SetBrowseFilter before the MoveNext OR using GetResultSets.where you can pass a condition for a DropShip=Y)
   
   
2. After your script verifies a UI is present, show a ProgressBar every so often. This solves this "is taking longer" msg the majority of the time. However I'm not sure a UI is detected when ScanForce creates the order.
   
   
3. By default the WSH allows 10 second timeout before showing you that msg but you can add for example ScriptTimeout=60000 to the server's SOTA.INI in the [Config] section. Now you get a 60 second timeout. The user would need to close out of Sage and restart it for it take effect.

Janna, short answer is YES! The message, "The script you are executing is taking longer than expected to run.  Click Cancel to abort  the script, or OK to continue the script execution" is a very old one that's built into and generated by the Windows Scripting Host or Tablacus in this case. It's telling you as the user, hey this script seems to be unresponsive and maybe it's stuck and you want to end it. To make the script more responsive, you have to implement 1 of the 3 suggestions. That's a great idea you have to only conditionally loop thru your script. That will probably take care of it.

Alnoor, so you think it's the VB script that's creating the Tablacus time out error?  I'm in the process of having the script look for a header field first to eliminate the loop through if a header field is no.  Will look at your other suggestions as well.

Janna,

The Tablacus Script Control 64-bit is an interesting platform that is an alternative to the Windows Scripting Host (WSH) we use today. It could be what we all need to use when future versions of Windows start to deprecate then eventually retire VBScript. I haven't tried it out myself yet though.

Assuming the "is taking longer" message is the same as was what WSH would tell you, here are 3 things you can potentially do:

1. Make sure the script is designed to run as efficiently as possible. For example, I see PreTotals scripts with Do Until/While Loops that scan thru the Lines but don't have an "Exit Do" line when the condition it's looking for is met, meaning it ends up scanning all the lines. Also depending on the purpose of the script, there might be a faster way to find the drop ship line (such as using SetBrowseFilter before the MoveNext OR using GetResultSets.where you can pass a condition for a DropShip=Y)
   
   
2. After your script verifies a UI is present, show a ProgressBar every so often. This solves this "is taking longer" msg the majority of the time. However I'm not sure a UI is detected when ScanForce creates the order.
   
   
3. By default the WSH allows 10 second timeout before showing you that msg but you can add for example ScriptTimeout=60000 to the server's SOTA.INI in the [Config] section. Now you get a 60 second timeout. The user would need to close out of Sage and restart it for it take effect.

if oBusObj.FromScanForce <> 1

' this means that the process thread is not a ScanForce import... may need to use oHeaderObj if a detail table event trigger.

Janna, short answer is YES! The message, "The script you are executing is taking longer than expected to run.  Click Cancel to abort  the script, or OK to continue the script execution" is a very old one that's built into and generated by the Windows Scripting Host or Tablacus in this case. It's telling you as the user, hey this script seems to be unresponsive and maybe it's stuck and you want to end it. To make the script more responsive, you have to implement 1 of the 3 suggestions. That's a great idea you have to only conditionally loop thru your script. That will probably take care of it.

Alnoor, so you think it's the VB script that's creating the Tablacus time out error?  I'm in the process of having the script look for a header field first to eliminate the loop through if a header field is no.  Will look at your other suggestions as well.

Janna,

The Tablacus Script Control 64-bit is an interesting platform that is an alternative to the Windows Scripting Host (WSH) we use today. It could be what we all need to use when future versions of Windows start to deprecate then eventually retire VBScript. I haven't tried it out myself yet though.

Assuming the "is taking longer" message is the same as was what WSH would tell you, here are 3 things you can potentially do:

1. Make sure the script is designed to run as efficiently as possible. For example, I see PreTotals scripts with Do Until/While Loops that scan thru the Lines but don't have an "Exit Do" line when the condition it's looking for is met, meaning it ends up scanning all the lines. Also depending on the purpose of the script, there might be a faster way to find the drop ship line (such as using SetBrowseFilter before the MoveNext OR using GetResultSets.where you can pass a condition for a DropShip=Y)
   
   
2. After your script verifies a UI is present, show a ProgressBar every so often. This solves this "is taking longer" msg the majority of the time. However I'm not sure a UI is detected when ScanForce creates the order.
   
   
3. By default the WSH allows 10 second timeout before showing you that msg but you can add for example ScriptTimeout=60000 to the server's SOTA.INI in the [Config] section. Now you get a 60 second timeout. The user would need to close out of Sage and restart it for it take effect.

Great point Kevin! If the script doesn't need to run when ScanForce is processing the order, then check for the FromScanForce property.

if oBusObj.FromScanForce <> 1

' this means that the process thread is not a ScanForce import... may need to use oHeaderObj if a detail table event trigger.

Janna, short answer is YES! The message, "The script you are executing is taking longer than expected to run.  Click Cancel to abort  the script, or OK to continue the script execution" is a very old one that's built into and generated by the Windows Scripting Host or Tablacus in this case. It's telling you as the user, hey this script seems to be unresponsive and maybe it's stuck and you want to end it. To make the script more responsive, you have to implement 1 of the 3 suggestions. That's a great idea you have to only conditionally loop thru your script. That will probably take care of it.

Alnoor, so you think it's the VB script that's creating the Tablacus time out error?  I'm in the process of having the script look for a header field first to eliminate the loop through if a header field is no.  Will look at your other suggestions as well.

Janna,

The Tablacus Script Control 64-bit is an interesting platform that is an alternative to the Windows Scripting Host (WSH) we use today. It could be what we all need to use when future versions of Windows start to deprecate then eventually retire VBScript. I haven't tried it out myself yet though.

Assuming the "is taking longer" message is the same as was what WSH would tell you, here are 3 things you can potentially do:

1. Make sure the script is designed to run as efficiently as possible. For example, I see PreTotals scripts with Do Until/While Loops that scan thru the Lines but don't have an "Exit Do" line when the condition it's looking for is met, meaning it ends up scanning all the lines. Also depending on the purpose of the script, there might be a faster way to find the drop ship line (such as using SetBrowseFilter before the MoveNext OR using GetResultSets.where you can pass a condition for a DropShip=Y)
   
   
2. After your script verifies a UI is present, show a ProgressBar every so often. This solves this "is taking longer" msg the majority of the time. However I'm not sure a UI is detected when ScanForce creates the order.
   
   
3. By default the WSH allows 10 second timeout before showing you that msg but you can add for example ScriptTimeout=60000 to the server's SOTA.INI in the [Config] section. Now you get a 60 second timeout. The user would need to close out of Sage and restart it for it take effect.