Troubleshooting


  1. WatchConnect doesn't work!
  2. Help! nnCron won't let me to edit my task via GUI!
  3. WatchWin* doesn't work properly with Command Prompt window...
  4. nnCron can't "catch" the application window I need. What's the deal?
  5. Tasks using word IDLE: start at wrong times!
  6. nnCron started to tall back when I try to use words VARIABLE, CREATE... Why?
  7. WatchDir: and WatchFile: don't work in Novell network and return "error ¹2". What can I do??
  8. Why can't I start an application from a network drive? Why applications which were started from nnCron cannot see network drives?
  9. I have set WatchHotKey: to start a task. After that, this hotkey combination lost the functions it used to perform in other appliations: each time I press this hotkey, the nnCron task is started, no matter what application I'm working in. What's wrong?
  10. nnCron icon is not showing up in system tray if nnCron is used under Terminal Server (Remote Desktop). What is wrong there?
  11. I'm receiving 'Error opening file for writing: nnhook.dll' message when I'm trying to install new nnCron build over the previous one. Help, please!
  12. Why do I receive the syntax error when trying to declare a variable right after Rule:?
  13. If there are some limitations in nnCron: maximum crontab size, maximum crontab line length, maximum tasks count?

WatchConnect doesn't work!

Words WatchConnect and WatchDisconnect work only in Windows NT/2000/XP.


Help! nnCron won't let me to edit my task via GUI!

Yes, that is true. Only relatively simple, "easy-to-formalize" tasks can be edited with the help of GUI. Complex task, including a lot of Forth code, regexps, Windows scripting etc., in most cases can only be edited manually, by modifying their source code.


WatchWin* doesn't work properly with Command Prompt window...

nnCron ignores console windows (this is a limitation of Windows OS).

Please keep in mind that word WIN-EXIST: can correctly handle console windows too. So you can try solve the task of "catching" console windows by periodically starting WIN-EXIST:.


nnCron can't "catch" the application window I need. What's the deal?

Most probably, this window has a parent window (probably, unseen) and WatchWin* words are working only with top-level windows (those which don't have a parent). You still can try to catch this child window using FOR-CHILD-WINDOWS: loop.


Tasks using word IDLE: start at wrong times!

It looks like you have run into another limitation of the OS: when some console window (Command Prompt, FAR etc.) is active, Windows ignores user's actions, and idle time counter goes on being incremented, regardless of user's activity.

To be more specific, in Widows 9* only keyboard input is ignored in such a situation, and mouse activity is processed correctly. In Windows 2000, both are ignored.


nnCron started to talk back when I try to use words VARIABLE, CREATE... Why?

nnCron has an option to limit the variety of syntactic constructs which can be used in the beginning of the task definition. File nncron.ini contains a special variable SyntaxRestriction which is used for that purpose. Most likely, it is set to ON in your configuration.


WatchDir: and WatchFile: don't work in Novell network and return "error ¹2". What can I do?

"Error ¹2" is ERROR_FILE_NOT_FOUND: The system cannot find the file specified. Another possible error is error ¹50: The network request is not supported. ERROR_NOT_SUPPORTED.

According to Nicholas, WatchDir: and WatchFile: don't work under Novell yet and hardly will work in near future. Since we have no definite hopes in this respect, I recommend to periodically check for the required file/directory by using FILE-EXIST:; this is just as good as Watch*, as far as functionality is concerned, although, of course, a bit more complex. :)


Why can't I start an application from a network drive? Why applications which were started from nnCron cannot see network drives?

It is because under Windows NT/2000/ÕÐ, nnCron is started as a system service run by SYSTEM (this is a built-in user account). And user SYSTEM doesn't have enough rights to access network drives.

There are several ways to solve this problem:


I have set WatchHotKey: to start a task. After that, this hotkey combination lost the functions it used to perform in other appliations: each time I press this hotkey, the nnCron task is started, no matter what application I'm working in. What's wrong?

Since version 1.89b8, nnCron can pass hotkeys to other apps when the task can not be started by WatchHotKey: because of Rule: or Time:. Thus, if you want some apps to receive the same key combination, which is used by nnCron, you can mention these apps in Rule:

#( test_watchhotkey
WatchHotKey: "^s"
\ pass this hotkey to other apps when  'notepad.exe' and 
\ 'bred2.exe' are loaded
Rule: PROC-EXIST: "notepad.exe" 0= PROC-EXIST: "bred2.exe" 0= AND 
Action:
    MSG: "beep"
)#

You can manipulate with Time: as well:

#( test_watchhotkey1
WatchHotKey: "^@s"
\ pass this hotkey to other apps when current time is not
\ falling to the time slice 14:00-18:00
Time: * 14-18 
Action:
    MSG: "beep"
)# 

nnCron icon is not showing up in system tray if nnCron is used under Terminal Server (Remote Desktop). What is wrong there?

Just start nnCron not as system service, but as a regular application (using command line switch -ns). This eliminates most of the problems, which arise when nnCron is used under Terminal Server/Remote Desktop.


I'm receiving 'Error opening file for writing: nnhook.dll' message when I'm trying to install new nnCron build over the previous one. Help, please!

Yes, sometimes nnhook.dll becomes locked by one of the processes, making impossible to delete or overwrite this file. Fortunately, there is an easy workaround for this problem: just rename the locked file nnhook.dll manually and start nnCron installation once again. You can safely delete the renamed nnhook.dll after the the next computer boot.


Why do I receive the syntax error when trying to declare a variable right after Rule:?

Keep in mind, that when you are defining a Rule: you are actually defining a new Forth word without a title (:NONAME). There is no easy way to determine where this new Forth word definition stops. Therefore, when you are adding some code right after Rule:, nnCron thinks of it as of the Rule: continuation and gives you a syntax error.

The easyest way to solve this problem is to move your variable/array declarations to the beginning of the task (so they resides just before Rule:). If this is impossible for some reason, you can use the Forth word ';' to stop the Rule: definition in an explicit way.

Example:

#( test_rule 
NoActive
Rule: ... ;
VARIABLE vtest   
CREATE stest 256 ALLOT
Action:
    \ ...
)#

Info for the curious users: the Action: is a special IMMEDIATE Forth word. This word explicitely stops the previous word definition (if any) and starts the new one. This is why you are not receiving syntax errors when using Action: right after Rule:.


If there are some limitations in nnCron: maximum crontab size, maximum crontab line length, maximum tasks count?

There is only one known limitation: the maximum length of a line in a crontab should not exceed 512 symbols.
Every nnCron task is silently compiled into independent Forth-word and is stored in a common Forth-dictionary, which allocates 1024 KB of memory. The words from nnCron core are stored in the same memory area as well. Thus, there are around 600 KB of free memory available for storing the compiled tasks: enough to store more than 2000 tasks - quite reasonable limitation.