Invalid connections to aggregate objects

[Toma]

There was a message "This program has performed illegal operation ..."
when exiting Lookout. Unfortunately I didn't notice in what module(s).

After I started Lookout again all the connections to aggregate objects
didn't work any longer.

Now Lookout became absolutely inoperational.

Once I open a process containing aggregates 'connections'
dialog displays wrong and non-existing connections like
PotHysteresis.value_i= \\hp\hidden_Temperature_Sensor_1\PotHysteresis.value

When I close Lookout after deleting these invalid connections
I'm getting 2 error messages :

LOOKOUT caused an invalid page fault in
module LKWORKS.DLL at 0167:0061470c.

and

LOOKOUT caused an invalid page fault in
module KERNEL32.DLL at 0167:bff7b9a6.


At the
same time lks files are OK.

I tried to launch my backup files what worked OK a couple
of hours back it didn't work.

I reinstalled Lookout - it didn't help as well.

I need an urgent help on that I didn't manage to get our
furnaces working today. I only have time until tomorrow
afternoon to fix it all up.

Our operating system is Win98SE, Lookout is 4.5.1.18.
Updating files to 4.5.1.19 didn't help.

Best regards,
Sergei Modebadze

[Roli]

Hi Sergei

this looks like it is a bug in the aggregate part of Lookout. I would recommend to send all your information (aggregate process files, your process file, ini files, drwatson.log file)... to www.ni.com/ask or you contcat National Instruments support.
If National Instruments cannot locate the error it is maybe a corrupted process file you've got when you saw the crash. In this case recompiling the *.lks files might help. Or you ask again NI for help.

Regards
Roland

[Toma]

Hi Roland,

I'm sure you are right - there must be a bug in
aggregate object of Lookout. I came across this
problem twice in a couple of days. Lks were correct
and recompiling didn't help. I had to make a 'clean'
Lookout reinstall to get it fixed up.

Moreover it seems there are several bugs in aggregate.

For example, with nested aggregates linked like
Main.Aggregate1->Sub1.Aggregate1->Sub2, if
Sub2 contain customs graphic then Main will display
wrong customs graphic, though all of .lks are correct.

I tested this with Lookout 4.5.1.18 on Win98
and Win2000 - the bug is evident in 100% cases.

I already reported this problem to NI and I sent
them my sample files along with screenshots showing
wrong graphic display.

Meantime, it would be interesting to test this
ag
gregate behavior with other Lookout versions/builds.

Would you like to take a look at my files?


Best regards,
Sergei

Roli wrote:

> Hi Sergei
>
> this looks like it is a bug in the aggregate part of Lookout. I would
> recommend to send all your information (aggregate process files, your
> process file, ini files, drwatson.log file)... to www.ni.com/ask or
> you contcat National Instruments support.
> If National Instruments cannot locate the error it is maybe a
> corrupted process file you've got when you saw the crash. In this case
> recompiling the *.lks files might help. Or you ask again NI for help.
>
> Regards
> Roland
>

[Roli]

Hi Sergei,

concerning the nested aggregate issue and the customs graphics I do not know what is going on. But if you report it to the support group with a 100% reproducable test file National Instruments Lookout R&D will fix it.

If you want to attache some files go ahead and I can take a look into it.

Regards
Roland

[Toma]

Hi Roland,

Can I have your address to send the files?

Regards,
Sergei


> If you want to attache some files go ahead and I can take a look into
> it.
>
> Regards
> Roland
>

[Roli]

roli@openworld.ch or obviously
roland.hofstetter@ni.com

Let me know.
Roland

[Toma]

Hi Roland,

Hope you got my files showing
wrong custom graphic with nested aggregates.
Just checked with Lookout 5.0 - the
bug is still there.

Sergei

Roli wrote:

> roli@openworld.ch or obviously
> roland.hofstetter@ni.com
>
> Let me know.
> Roland
>

[Toma]

NI got the bug fixed!

Many thanks to NI people for
taking care of resolving the problem
promptly.

Sergei