Search results for query: *

One last note. I apologize for the confusion about originally considering either BOLD or Shaded. After reviewing the document, I discovered that ALL TextBox fields were already Bolded so that eliminated that as a possible change option to draw the reader's attention to individually Marked...

Dave - you got it!!! I did not see the Mode property changed when I tested this via VFP's Report Designer, but it was indeed the missing piece that made the Background Color show as intended. Thanks, I_Forgot

Thanks for your continued interest and replies. Rick - I did not realize that the Preview also used a Print Driver. Since the Preview appears on-screen, it did not come to mind. However in this particular instance, after writing the new FillRed, FillGreen, & FillBlue values, I do a LOCATE...

Rick - Yes it was the same printer each time. My first test did not use any printer at all, but instead the Report Preview mode -- where the problem was first noticed in the different on-screen results. I have also hacked the Report table's EXPR, TAG, & TAG2 memo fields to eliminate any of...

I thought that I had this issue worked out, but now I am not so certain. When I manually modify a Report Form's TextBox Fill Color throught Foxpro's Report Designer, I get what I want. And the Report displays correctly in the Preview mode. I then examine the Report Form's DBF (in reality...

By 'playing' around in the Report Form's table I have found one way to programatically change the Report TextBox's properties. I can set new values into the specific TextBox's FillRed FillBlue FillGreen Or I could change the FontStyle to a 1 for BOLD And then I could return the...

I want to find out if there is a way to programatically change the TextBox Properties of a Report Form. My users want to BOLD the text in a Grid's single TextBox by clicking on some button. I don't think that this will be too hard by using DynamicFontBold and, at the same time, I should be...

From FAQ184-2919 "And in the gray band of page header of your report (The first of three bands), in the "on entry" textbox put PRINTED()" What "On Entry" Textbox ?? My VFP7 Report Forms do not have access to any TextBoxes within the Gray Bands. Yes, I can add a new Field TextBox within...

...on a Grid's Row when a record is printed. Consequently I give them a intermediary selection form prior to Printing with the following choices: * Print * Preview * Cancel And, based on their choice, I execute the appropriate REPORT FORM MyReport NEXT 1.... code. If they actually Print...

Just a follow-up... I quit attempting to make this happen with the Remote View Designer - New Remote View Instead I ended up building a CREATE VIEW programatically and including the "hidden" field. By doing so I avoided any limitations which might have been occuring as a result of using the...

...doing an ADD merely adds a string Constant field whose value is "RowID" instead of adding the field to the query. I also though about using the * (entered through the "Functions and Expressions window) in the SQL statement along with a qualifying WHERE RowID > 0, but: 1. The * did not work...

...will not appear within the Remote View designer. Within the "native" system Linux box if you perform a "normal" SQL query such as: SELECT * FROM MyTable on one of these tables, its results will also NOT display this "hidden" field (rowid). But if you specifically include the field...

...will not appear within the Remote View designer. Within the "native" system Linux box if you perform a "normal" SQL query such as: SELECT * FROM MyTable on one of these tables, its results will also NOT display this "hidden" field (rowid). But if you specifically include the field...

...this "hidden" field will not appear within the Remote View designer. Within the Linux box if you perform a "normal" SQL query such as: SELECT * FROM MyTable on one of these tables, its results will also not display this "hidden" field (rowid). But if you specifically include the...

Making the custom subclass does indeed sound like the way to go so that the new property is available everytime I need it. You say that making a subclass is "so easy", but my stumbling around through VFP7's various menus has not shown me how to do it. Without taking too much of your time...

Do I have a good reason for not wanting to use a Custom TextBox class? Not really. But since the new OrigValue property could potentially be of value EVERY time I want to use ANY TextBox, it seems as though it would just be MUCH easier to change the default TextBox class instead of having to...

Without creating a totally new custom class, can I just add a new property to the VFP7 existing TextBox Base Class. I would like to add a Property to hold the TextBox's Original Value (from When method) which can be later compared against the possible New value (in Valid method). Like Marcia...

My progress has been slow, but at least it has been primarily in the forward direction... Originally I had Deleted the TextBox from the ComboBox Columns, but I was advised to add them back in. Now I have added them (one per column) back in. I have also set the initial properites as follows...

...the ComboBox WHEN Method to interrogate the 'child' table for the appropriate values and then, similar to above, I populate the ComboBox 'rows'. * --- From Grid's ComboBox WHEN Method --- SELECT Table_1 mcParentVal = Table_1.Field1 mcValue = This.DisplayValue IF EMPTY(mcValue) * --- Only...

...through the Grid records. SELECT Table_1 && "Parent" table mcAppl = Table_1.Field1 && <<-- Common Field Value Between Tables FOR i = 4 TO 6 * --- Only ComboBox Columns 4, 5, & 6 --- WITH THISFORM.PAGEFRAME.TabPage3.Grid.COLUMNS[i] .ComboBox.RowSourceType = 0...