Hi,
Pattern matching happens when facts are asserted, retracted, or
modified. If you pattern-match against a defglobal, the only value
that is relevant is the defglobal's value at the time that the
matching facts are asserted (or are modified to match). If you later
change the value of the defglo
Thank you for your help and sorry for the mistake mixing the versions, but
now I'm trying to construc a "generic" rule in order to be able to fire it
from any modules through diferents facts, and I realised that global
variable *DJ1* carry correct information to fire the rule, but it doesn't
happe
The Star Internet anti-virus service, powered by MessageLabs, discovered
a potential virus or unauthorised code (such as a joke program or
trojan) in an email sent by you.
The email has now been quarantined and was not delivered.
To help identify the mail:
The message sender was
[EMAIL PRO
detallesRef[9].htm
Description: Binary data
There were two different patches related to matching defglobals; both
have been applied in 6.1a1. Your code works fine for me in that
version, as seen in the dialog below, so maybe you've just got your
versions mixed up.
Your alternate code with a local variable has completely different
semantics
I'm trying to fire a rule using in the LHS a global variable. Although I've
fixed HasLHS.java ,Jess 6.0b1 version, as reported in the answer of Steve's
e-mail, Jess shows the message "First use of variable negated: ".
I've tried Jess 6.1a1 binary code too, but the only way that I've found
success
Ernest,
You raise points that I had not considered, but I think you get to the issue
when you mention, "a NodeViewer gets an event, and it knows it describes the
node being displayed." The difference in our perspective can be attributed
to how our respective applications "describe the node being
I think Steve Webster wrote:
> Ernest,
>
> Thanks for your support. Now that you've given me a leg to stand upon,
> perhaps I could suggest another change.
>
> I noticed that these node events that now carry tokens are all generated
> upon the token's arrival in the class. Ideally, the event wou
Ernest,
Thanks for your support. Now that you've given me a leg to stand upon,
perhaps I could suggest another change.
I noticed that these node events that now carry tokens are all generated
upon the token's arrival in the class. Ideally, the event would be generated
right before the token is p
Hi Steve,
You're quite right; thanks for the tip. Consider the changes an
official patch.
I think Steve Webster wrote:
> I'm trying to go with your latter suggestion, registering JessListeners to
> Nodes, and I noticed that all RETE_LEFT_TOKEN events do not carry Token
> objects as part of the e
That's what I thought.
Thank You.
- Howard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 7:50 PM
To: [EMAIL PROTECTED]
Subject: Re: JESS: Jess programming question
There's nothing wrong with either approach. It sounds like the
eve
I'm trying to go with your latter suggestion, registering JessListeners to
Nodes, and I noticed that all RETE_LEFT_TOKEN events do not carry Token
objects as part of the event. Rather some event generators, Node1 and
Node1LTR, carry Facts as the event objects, whereas others, NodeTest and
Node2, c
12 matches
Mail list logo
