Disabling textboxes..

[arc42]

I have 2 forms, one is the main form and the other one is for the details.
The first form consists of a grid and add,edit,delete commands.
The other one consists of textboxes with labels to input necessary details such as idno, name, address, etc.
When clicking the Add command all textboxes are set to enabled = true
My problem is...
When clicking the Edit button I want the idno and name textboxes to be enabled = false and the others true.
I have this codes in the init of the second form:

PARAMETERS cMode
thisform.txtDate.Tag = ALLTRIM(cMode)
DO CASE
CASE VAL(cMode) = 1
thisform.txtID.Enabled = .t.
thisform.txtName.Enabled = .t.
thisform.txtAddress.Enabled = .t.
thisform.txtBdate.Enabled = .t.
thisform.txtAge.Enabled = .t.
thisform.txtStatus.Enabled = .t.
CASE VAL(cMode) = 2
thisform.txtID.Enabled = .f.
thisform.txtName.Enabled = .f.
thisform.txtAddress.Enabled = .t.
thisform.txtBdate.Enabled = .t.
thisform.txtAge.Enabled = .t.
thisform.txtStatus.Enabled = .t.
ENDCASE

And in the Add command (Click):
DO FORM frm_detl WITH "", 0, thisform.Tag

Edit command (Click):
DO FORM frm_detl WITH tmp_info.idno, 1, thisform.Tag

I can't figure why it doesn't work..
Really need your help...
Thanks!

 

[Mike Lewis]

The first thing I notice is that you are passing three parameters to the form, but the form is only receiving one of them.

Your Edit button's DO FORM command looks like this:

DO FORM frm_detl WITH tmp_info.idno, 1, thisform.Tag

but the Init of the detail form contains this:

PARAMETERS cMode

So the Init will think that tmp_info.idno is your cMode (andn will discard the other two parameters). Since that ID is probably more than 2, it will not execute either of the CASE conditions, so nothing will change in the form.

To fix it, change the PARAMETERS statement to something like this:

PARAMETERS nID, cMode, cTag

Give it a try.

Mike







__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[arc42]

I actually have this
PARAMETERS cScode, nWhatmode, cMode
in the init of the detail form..
I just forgot to include it here..

 

[Mike Lewis]

In that case, cMode is mapping to THISFORM.tag. So the CASE statement will expect the Tag property of the first form to be either 1 or 2, and will enable or disable accordingly. I don't think that's what you want.

I think it's more likely that you should be testing nWhatMode in the CASE, rather than VAL(cMode).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

You haven't understood the types the naming convention suggesst you to pass in. The parameter is called cMode, you pass 1 as cMode, which is not "C" as Char, but an integer.
Test Val(1) at the command line, it will error the same way as your form init.

Pass in "1" instead of 1.

You could also change init code, but assumed this form is already used as is in other places you would break their calls to the form, if you changed the parameter to accept numeric input values.

Bye, Olaf.

 

[arc42]

I tried both of your suggestions...but still didn't work..
I am very confused in this vfp...I'm still in a learning stage..
Hope you understand and hope you'll not quit helping me..Thanks to both of you..
I really want to learn it..

 

[Mike Lewis]

Arc42, you say you tried our suggestions. I'm sorry to hear they didn't work. But, really, there's more to this than simply pasting our code into your app and seeing if it works. You need to understand the code. We've explained the need to match the parameters in your DO FORM with those in the PARAMETERS statement. You need to understand that explanation, and work out how to apply it to your problem.

I appreciate that you are at an early stage. I would suggest that you read the relevant topics in the Help file to get you started, then come back here if you there is anything you don't understand. A good starting point would be the "Passing Data to Parameters" topic.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

The init code is expecting a string, not a number. VAL() expects a string parameter and errors on a numeric parameter.

All you should do is change your calling of the form to
DO FORM frm_detl WITH tmp_info.idno, "1", thisform.Tag

This means you pass in "1" and not 1. It's simply literally changing that.

I agree with Mike, it would help you more to learn and understand instead of just copying that over and see it works (or not, but then there would be something else we should also address).

Some general tipps, if something doesn't work out: Put a line "SET STEP ON" one line before the failing code.

This is a break point written as code line, which will be activating the VFP debugger at that point and then stop execution to let you control in the debugger what to do next. This is the most helpful tool to find out what's happening, you can then execute code step by step, each single line on it's own. You will need to remove that SET STEP ON later, but in the first place it's easier and more failsafe than visually setting a break point. Some will say SET STEP ON is bad, as you can forget it, but the good news is, even if you do, in the compiled version this command simply does nothing, it's ignored.

The debugger also has a bit of a learning curve, but for a start you can then Press F8 to execute the next line of code and then see where it fails. You can inspect the code itself in the trace window, hover with the mouse over a variable to get it's value displayed as tiptext or look into the locals window. If you stay with passing in 1 you'll see the code will error on the first line with VAL(cMode), as that needs to be a string. VAL returns the numeric value of a string, but it errors, if you provide a numeric value in the first place.

Bye, Olaf.

 

[JRB-Bldr]

I'm going to make a more general suggestion - a method to debug your code.

Get familiar with using the TRACE Window (ACTI WIND TRACE) and either Breakpoints and/or the SET STEP ON command.

Breakpoints will not 'break' unless the TRACE Window is already open, but SET STEP ON will automatically 'break' and open the TRACE Window for you (all in the Development mode).

By using one or both of these 2 debug methods (perhaps in the LOAD method of the 2nd form), you should be able to see what is being passed. Then, from there, you can SINGLE STEP or use other break points to find out why certain things are (or are not) occurring.

And from your break point, you can also use the WATCH Window to observe the values of objects, variables, array elements, etc. to see if they are getting set as you expect.

Good Luck,
JRB-Bldr

 

[craigber]

How would would a user enable the IdNo and Name textboxes? If they can't, they should be ReadOnly. There is a subtle display difference between ReadOnly and disabled. ReadOnly means you can't edit the field. Disabled means you can turn editing on and off.

A second thing to consider... does the user need to know or care about the IdNo? If not, it should not be displayed.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[TamarGranor]

As others have suggested, learning to use the Debugger will help you a lot. This paper from my website should get you going with the Debugger:

http://tomorrowssolutionsllc.com/Materials/debugger.html

Tamar