We load a lot more than that and basically do not even use a custom memory policy i.e. don't create our own subclass but rather just push the memory parameters up.

That helps, thanks, I'll look into it.
The database I had in mind was relatively small, only around 15,000 discreet data items.

Gary

this is really more of an issue of creating a custom memory policy to handle bulk loads gracefully. There is mechanism for counting i.e. based on how many instvars an object has  plus taking into account the object header and or course its a recursive process to understand the total weight of a particular object but I forget how things are weighted i.e. the byte count. Check out the advanced profilers parcel  there are some stats regarding memory consumption associated to a particular measured process. In a 64 bit vm the answer should be essentially any entire db could be cached in a VW image in a 32 bit vm the answer is quite a lot . In my shop we do "database caching".

hth,

Is there a way in VW to determine how much memory is being used by a particular object?

I realise that this may be someting of a "what if" type of question.
I ask because I would like to get an idea of how much data I can load into an image safely from a database.

---
vw7.7 nc
Windows XP Home SP3

As a quick test I filed in the package to a clean image and still got the same result.
G

k, now I"m curious. I'll look into but probably not until Monday.

Charles

I've tried using -
(self widgetAt: cmp) controller: ReadOnlyTextEditorController new.
but then clicking on the InputField causes an error -
   a Message with selector: #requestActivationFor: and arguments: #(a ReadOnlyTextEditorController)
so I abandoned that approach.

As you mentioned, disable seems a more straightforward approach, particularly as I will also disable certain action buttons.
However, I was still getting the same problem with the existing read-only input field -
#disable works okay but the input field's background then becomes white.

I've tried a number of variations in the code, with no success. I am wondering if this is a bug in vw7.7

In the end I got around the problem by amending the GUI source to include the following code as part of the problematic InputFieldSpec definition -
         #colors:
         #(#{UI.LookPreferences}
            #setBackgroundColor: #(#{Graphics.ColorValue} 7167 7167 7167 ) )
which effectively stopped the background turning white by stating its color explicitly as background gray (on my WinXP machine).
It's not ideal but it worked.

Thanks for you help (as always... as always... as always...)
Gary

7.7nc

Gary:

isReadOnly:

sets the boolean on the spec but the spec is only used upon UI building i.e. the spec is the blueprint for building. So it doesn't do you any good once the building has been built. The look policy during the building process queries the spec for this state i.e. "are you read only" and given that it will decide what controller to hook up to the view, "if read only" it then hooks up ReadOnlyTextEditorController

I don't recall any conveniences for this i.e. folks typically just disable , enable. However, you should be able to just set the controller i.e.

(self widgetAt: #entryNum) controller: ReadOnlyTextEditorController new.

conversely when you want to be input capable then:

(self widgetAt: #entryNum) controller: InputBoxController new.

hth

What version of VisualWorks is this?