I have this user-defined property that sometimes fails - Get_Property returns null, and the Debugger's Inspect Properties agrees. It seems to me it could be resource related. E.g, it happens more easily when lots of programs are running. Have anybody ever seen this happen? (Or it could be a bug-of-my-own related thing, but in that case the bug is well hidden…)

- Oystein -

Oystein ..

I think it's definitely resource related. I had exactly the same problem on one of our development machines a while back. It was traced to a fair number of things that got loaded during the startup/initialization process on the machine. Removing a couple of these items restored the functionality. FYI, the user property was the data in a record that had been read in a window. It could be null or it could be up to about 35K (with a lot of AMV's, but I don't think it mattered). Sometimes the Get_Property(@WINDOW,"@ORIG","DEFPROP") would return null when we knew it shouldn't was the symptom. Sounds just like yours. The desktop was Windows 98/SE with Netware Client32 version 3.30.0.0, TCP/IP also loaded due to a need to access an NT server, 128 MB memory, PIII 900 MhZ processor.

Don Miller

C3 Inc.

Oystein,

I have never experienced a UDP failure before, and we run applications that quite often consume every last resource. However, I never seem to get my UDPs to inspect correctly within the Debugger. I just assumed the Debugger wasn't designed to inspect them as they always returns as null.

[email protected]

SRP Computer Solutions, Inc.

Don B,

Thanks for reminding me about the Debugger's inability to show user-defined properties. I'd forgotten all about that.

Don M,

I think it's definitely resource related. I had exactly the same problem on one of our development machines a while back.

Did you post something about it? I had this vague feeling somebody reported a similar problem not too long ago, but wasn't able to find it.

If it is resource related - do you think the program could watch out for it by checking resources at key points in its code?

It was traced to a fair number of things that got loaded during the startup/initialization process on the machine. Removing a couple of these items restored the functionality.

Right. But what about your clients? How could you make sure they didn't get the problem?

FYI, the user property was the data in a record that had been read in a window.

Sounds similar to what I use my property for, but that must be a coincidence. The problem occurs in my MDI multipage window I've bored you all with a lot. Each page is a child window, and only one child is open at a time. The current unwritten record is stored in a user property of the frame. When the user changes page the temporary record is updated with the field values of the current (i.e, closing) child.

What goes wrong sometimes is when the user wants to write the record to disk. Then the temporary record is retrieved from the user property and updated with the field values of the current child. But sometimes the retrieved record is null. So what ends up written is a record with values only from the current child.

It seems to happen more often when there are many programs running. It seems to happen in just one particular child - one that's a bit more complex than the other ones.

Just to make one thing clear: The user property isn't nulled for real. Change to a different child and it's OK again.

It could be null or it could be up to about 35K (with a lot of AMV's, but I don't think it mattered).

My records have never been very large, but there is an edit table and quite a few MV fields in the problematic child.

Sometimes the Get_Property(@WINDOW,"@ORIG","DEFPROP")

Huh? Say that again?

would return null when we knew it shouldn't was the symptom. Sounds just like yours.

Was it either correct or null, and never corrupted in other ways? I could of course strengthen my code with a check on the retrieved value. If the value was null I must to bail out gracefully. But since my temporary record can be null for real, I'd have to extend my temporary record with a permanent dummy non-null field or something, so I could distinguish a bona-fide empty record from one swallowed by the bug.

But this wouldn't be a very satisfactory solution. I'd never know if the problem could surface elsewhere.

The desktop was Windows 98/SE with Netware Client32 version 3.30.0.0, TCP/IP also loaded due to a need to access an NT server, 128 MB memory, PIII 900 MhZ processor.

Here it's Windows 2000; Microsoft Network, TCP/IP, could be more - have to check at site tomorrow; 128 MB RAM, 1.3 GHz. That's really the only place the program has been run so far.

- Oystein -

Oystein ..

Just a thought. If you used @USERn as opposed to a user-defined element, maybe windows resources won't enter into the picture. I've tended to do this to pass data around between commuter modules and forms and have never had a problem. I don't know if there's any way within 16-bit windows code to get access to the state of desktop resources at any point in time. My belief is that @USER and @RECUR variables might be less prone to getting whacked than variables that are under control of presentation server or whatnot.

I think I posted something about this a loooooong time ago (maybe 2+ years, but I can't be sure). Maybe I talked to Cam Purdy about it when I went to their offices in Mass (since it was just up the road from me).. maybe Gene too .. just can't remember or CRS these days anyway.

Let me know how it works out.

Don Miller

C3 Inc.

Don,

I don't know if there's any way within 16-bit windows code to get access to the state of desktop resources at any point in time.

The following works:

Equ FREESYSTEMRESOURCES$ to 0

Equ FREEGDIRESOURCES$ to 1

Equ FREEUSERRESOURCES$ to 2

SystemResources=GetFreeSystemResources(FREESYSTEMRESOURCES$)

GDIResources =GetFreeSystemResources(FREEGDIRESOURCES$)

UserResources =GetFreeSystemResources(FREEUSERRESOURCES$)

I believe Sprezz uses these functions in S/List to prevent it from being loaded when resources are too low.

[email protected]

SRP Computer Solutions, Inc.

I forgot to add the following:

USHORT PASCAL GetFreeSystemResources(USHORT)

If you don't already have this defined as a USER API function then you'll need to add this or create a new entry for it.

[email protected]

SRP Computer Solutions, Inc.

Don,

Nice try, but unfortunately this frame of mine can be present in more than one instance. So I need a variable or property that is local to each instance.

The frame has also got several other (20?) user defined properties storing small chunks of instance-dependent data. I assume they are all at risk.

Perhaps I could write some memory allocation routines that get and set all these properties. Behind the scenes I'll store everything in @USERn like you suggest. Just something for a project that's very much delayed already…

No, I won't do it!!!!!

- Oystein -

Don,

I know about the GetFreeSystemResources function and have planned to use it when the app wants to bring up another instance of the frame, to judge if it's safe. I've already used it a couple of other places to monitor resources, during development. What i did then was to display the level of available resources in three temporary edit controls. I've just not come around to use it in this new situation. I'm mostly posting from home where I don't do development work, while being busy with other stuff at work.

- Oystein -

Don,

Do you know if this type of resource problem also happens with variable labelled commons?

Cheers, M@

All,

Seems there's a bug in my own code that clears that problematic user-defined property of mine. Sorry.

I thought I saw a pattern that could be explained by depleted resources. Now I've checked resources and they are all at 90% even when things go wrong.

And for a while this bug of mine hid behind another bug.

- Oystein -

Matthew,

I just posted a message where I confess the problem I had with user-defined properties being cleared happened because of a bug of my own.

And I've never seen any such problems with variable labelled commonblocks. I use such commonblocks, but in moderation.

- Oystein -

View this thread on the Works forum...