Multi line grid field condition 2

[Phil Thoms]

Hello,
I have a multi line grid that I created in VFP6 (YES a multi line grid) it works superbly and is accessed on a daily basis with new data.
However, I wish to place a condition on a table field called quantity. When the quantity field is greater than 1 then I would like it to display in red.
I know this is straight forward in a normal grid with dynamic properties but I can't manage to achieve it in my multi grid.
For your information:-
I have constructed the multi line grid with several text fields inside a container with control sources from a table, the container has then been bound to a column within the grid.

Your help would be gratefully received.

Thanks.

 

[Mike Lewis]

Maybe a good thing to do at this stage would be to start again with the simplest case. In other words, start a new form, place an ordinary grid on it, then try replacing the built-in textbox (in the first column) with any other control - a native checkbox for example.

After you get that working, start again with another form and another grid, and this time add your custom container in place of the built-in textbox.

Keep going in that way until you have created the full multi-line grid that you were aiming for.

One point about all this is that you will probably need to set the RecordSource before you starting adding controls to the column. This is not essential, but it will avoid problems that can happen when you change the RecordSource after you have set up the grid. So start by setting the RecordSource at design time - at least until you are more comfortable with the way this all works.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Phil Thoms]

Mike,
Thanks for your previous comments.
However, in the meantime I managed to get the container class into the grid which works fine but the forecolor isn't changing when the field>quantity is greater than 1. I've checked that I've typed your coding correctly and all is OK.
I was able to get the class into the grid by using Tools>Options>Controls and setting the class as default. The class then appeared in the form controls toolbar when I opened the form. I haven't discovered the drag and drop method yet.
So, it's almost there.

PT

 

[Mike Lewis]

Good. You're making progress.

The next thing to try is to run some simpler code in the method. Try something like [tt]WAIT WINDOW "OK" NOWAIT[/tt]. If you see the Wait message on the screen while the form is running, that will at least tell you that the method is being executed. If it is, we can try to work out why the actual code isn't working.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Phil Thoms]

Mike,
To save some time the following is the code in the backstyle access procedure at present:-

IF Atest.qty>1
THIS.ForeColor = 255
ELSE
THIS.Forecolor = 0
ENDIF

RETURN THIS.backstyle

I may have misinterpreted this somewhere along the way.

Thanks.

 

[Olaf Doschke]

The container forecolor will not reflect in any textbox forecolor within the container. You have to set the containers controls forecolor properties. or you set the container to be opaque and set its backcolor. That'd assume your container is also acting as a frame around the controls you put into it and you keep margins around textboxes instead of packing them into the container sid by side like grid cells.

Bye, Olaf.

 

[Mike Lewis]

This is exactly why I chose the BorderColor property in my example code. As Olaf says, setting the container's foreground colour does not have any effect.

Try this instead:

IF Atest.qty>1
  THIS.SetAll("ForeColor", 255)
ELSE
  THIS.SetAll("ForeColor", 0)
ENDIF

RETURN THIS.backstyle

That will set the foreground colour of each of the controls in the container.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Phil Thoms]

Olaf and Mike,
The container is set as opaque. The textbox controls are framed with margins and not packed together like columns.

Thanks

 

[Phil Thoms]

Mike,
Thanks for your reply.
Is SETALL supported in VFP6 ?

PT

 

[Phil Thoms]

Mike,
Ignore previous comment.
Eureka! this works BUT I had a test version of the multi container with 2 fields ID and QTY and both these fields display in red when qty greater than 1.
So it's nearly there.

PT

 

[Mike Lewis]

Good. So now you have a proof of concept. It only remains to fill in the details.

Keep us informed.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If you don't want all forecolors set, then why don't you set the one forecolor in the one control you want changed? For example, if the textbox displaying QTY is named txtQTY set This.txtQTY.Forecolor = 255 (or 0 respectively). You are in a method of the container, so THIS is the container, controls contained in it are addressed via THIS.Controlname. You know how you named your containers textboxes, don't you? Even if you don't named them, you know their names will be Text1, Text2,..., don't you? You know how to address controls, don't you?

Or (as you say your container is visible opaque and as margin, you might simply set its backcolor. It's forecolor is useless, as a container has no text in it, unless you output text to it via ?-command. All controls you put on the container have their own .Forecolor property, that's why the container.forecolor has no visible effect, that's why Setall works, but sets all controls forecolors.

Or, as my sample code does, you might define a textbox class with a Change method as I did, then let the Container.backstyle_access method just call the textbox.Change() method and put each individual behaviour for each single textbox into the textboxes itself, i.e. setting their own forecolor via THIS.Forecolor.

Bye, Olaf.

 

[Phil Thoms]

Thanks Mike and Olaf.
Olaf,
Fully aware of your comments in paragraph no.1 and I'm now aware of your comments in para no.2.
Yours sample code textbox.change() seems a good way of employing the individual textbox's. Some more thought on my part is now required.

I will keep you both informed and many thanks.

PT

 

[Phil Thoms]

Olaf and Mike,
Eureka! again.
I used Olaf's suggestion no.1 in last reply - This.text2.forecolor etc., and of course Mike's previous suggestions - works perfectly.

Thanks to you both. One can learn a lot from a routine query.

PT

 

[Mike Lewis]

Good to hear that you've finally got it working.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Phil Thoms]

Mike and Olaf,
Realised this morning that I tried this code in the INIT property of the container (didn't work) a couple of weeks before I triggered this query, so I was on the right tracks before you mentioned the Backstyle_access method:-

IF Atest.qty>1
THIS.Text2.foreColor = 255
ELSE
THIS.Text2.foreColor = 0
ENDIF

You may put me right on this, but I can't understand why most properties can't be conditioned with the IIF statement, it would make things easier, possibly.

Once again, many thanks.

PT

 

[Mike Lewis]

Well, if the code is in your Init, it will only execute when the grid first appears. Presumably, what you want is for the colours to be updated whenever the contents of the grid changes. That's why you use the BackStyle_Access method.

You ask why you can't use IIF(). If you are asking if you can use IIF() instead of IF/ELSE/ENDIF, then of course you can.

This code:

THIS.Text2.foreColor = IIF(Atest.qty > 1, 255, 0)

is exactly the same as this:

IF Atest.qty>1
  THIS.Text2.foreColor = 255
ELSE
  THIS.Text2.foreColor = 0
ENDIF

but of course it is more concise. But I'm not sure if that is what you are asking.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

You can't put IIF(Atest.qty > 1, 255, 0) directly into the forecolor property of anything displayed in the grid, as it's not a DynamicXYZ property, only the dynamic properties are evaluated dynamically during grid refresh/draw repeatedly. Every other property will only be evaluate once at init and that's not enough. The IIF will be evaluated as one of it's two alternative values and that'd be set once and for all rows. The backstyle_access just coincidentally is one of the event like methods you can use because the grid itself calls into it, when it exists, When it not exists, the grid does read the backstyle property, which in itself is not dynamic (so the trick actually is, that any read property can be used as event by defining an access method, if you know it's read). You can't make Forecolor dynamic in the same way, when you define a Forecolor_access method, because the grid only accesses the backstyle, it doesn't access the forecolor of grid column controls, the Draw method must do it, because of cause the forecolor of things must be used for drawing them, still not every read has the same event driven nature, if a property is not seen as dynamic, reading it once is enough to know it, isn't it? So we can assume many things are only read once and then known as what they are. We don't really have that much insight into all things happening behind the scenes, but when trying forecolor_access and not succeeding you can make the assumption it's not read for every row drawing, as simple as that.

That backstyle_access works is kind of a hack or leak of info from the VFP team (RIP) and/or a discovery of simply trying it out. So it has become one additional quasi dynamic property, but of course any dynamic behaviour depends on what the grid itself natively does, you can't force anything upon it, just by setting properties to IIF expressions. Any normal property just evaluates such expressions (everything starting with = indeed, not only IIFs) but only once at initialsation. Such expressions are not working as dynamic as - giving another example - filter expression do, so the dynamic properties are an exception to the rule, just like the expressions you set on a workarea via SET FILTER are an exception, you also can't SET FIELDS TO IIF(....) and expect a browse to show differing fields per row depending on conditions per certain field values.

And in regard to the Dynamic Properties, you can also make a call to a method in there, it doesn't need to be IIF or ICASE, those are just the simplest expressions, which can evaluate to different results dynamically. You could also set DynamicForecolor to a certain constant RGB value, but then you may also simply set the normal forecolor to that value. This all is mainly controlled by the dynamic nature of dynamic functions and backstyle_access is kind of a ´black sheep of this family. It's that, which is causing the dynamic reevaluation, not the IIF function, not having any expression. If you want to do the same with any other property, you would need to define an extra property for the expression and at runtime, when needed set [tt]object.property=evaluate(object.expressionproperty)[/tt], that would be all code needed to replicate this behaviour, but you need any kind of trigger for this code, any event happening or at least a timer. Dynamic properties are triggered by drawing the grid rows, that's simply their base behavior. What we can't do in VFP is define such base behaviour, we can only react to events, not define/declare and cause them. Even the backstyle_sccess usage is just a hooking into the already existing events and things happening, it's making use of the grid reading that property not only once, but everytime a grid row is drawn.

Bye, Olaf.

 

[Phil Thoms]

Olaf,
Interesting and very useful info.

Mike and Olaf,
Thanks for your guidance, all is working well and looking good.

PT

 

[Phil Thoms]

Mike and/or Olaf,
Rather than start another thread, I am trying to do more than 1 condition for backstyle_access but it only does 1. I have the first one which works OK as previously stated but I've tried another similar one on text3 without success.
If you think I should start another thread, I will.
Thanks.

PT

 

[Mike Lewis]

Personally I don't feel you should start a new thread in this case. Your new problem is really an extension of the original question. With a new thread, anyone coming to it fresh would not know all the background information contained above.

Why not go ahead and post the code you now have in your backstyle_access, and we will see if we can spot the cause of the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads