Guriddo » r.cappa's Replies

r.cappa

Guriddo

Forum Replies Created

Viewing 15 replies - 1 through 15 (of 16 total)

1 2 →

Author

Replies
August 6, 2011 at 7:04 pm in reply to: Form editing: difference between add and edit. #98559

r.cappa
Participant

JerryOfPerth said:

r.cappa said:

Hii, in the documentation it seems that a single colModel property (“editable”) specifies if a column must be present in the add panel and the edit panel , but in large number of cases colmuns that I can set in an “add” operation must be not modifiable in “edit” mode (i.e. primary keys, Is there a way to obtain this behaviour?

Thanks

If you haven't already found a solution this might help:

jqGrid: Disable form fields when editing

I've already found this, but it is a workaround. It is not a good way, and not so much intuitive, manually hide unused fields in beforeshow event. It can be useful to configure this in a declarative mode.

July 5, 2011 at 9:43 pm in reply to: Possibile bug in “mtype” option inside add/edit options. #98412

r.cappa
Participant

It's perfect! Thanks!

July 5, 2011 at 10:29 am in reply to: tree grid simultaneous loading #98406

r.cappa
Participant

I have the same problem.

July 4, 2011 at 11:40 pm in reply to: Possibile bug in “mtype” option inside add/edit options. #98404

r.cappa
Participant

Hi, this is the form editor fragment configuration:

I'm testing it with Firebugs, that shows the HTTP operation when the data is posted to the server. So, the operation is performed correctly but the first choice between add and edit force the HTTP operation for following invocations.

July 4, 2011 at 8:59 pm in reply to: Possibile bug in “mtype” option inside add/edit options. #98400

r.cappa
Participant

Hi, unfortunately it doesn't work. I verified with debugger that the lines you have changed are executed, the rp_ge object contains the correct “mtype” value after that, but at submit the wrong operation is performed.

Thanks.

June 30, 2011 at 5:49 pm in reply to: Possibile bug in “mtype” option inside add/edit options. #98374

r.cappa
Participant

tony said:

Hello,

We will fix this very soon.

The behaviour is available since 4.1 and maybe we will go back to fix this error which is more important

Thank you.

Regards

Tony

One question: in mean time the bug is fixing, is there any workaround to get working this scenario in 4.1.1? Thanks

June 27, 2011 at 9:59 pm in reply to: Possibile bug in “mtype” option inside add/edit options. #98349

r.cappa
Participant

tony said:

Hello,

We will fix this very soon.

The behaviour is available since 4.1 and maybe we will go back to fix this error which is more important

Thank you.

Regards

Tony

Thanks Tony!

June 27, 2011 at 9:16 pm in reply to: Possibile bug in “mtype” option inside add/edit options. #98346

r.cappa
Participant

Bugzee said:

The mtype is shared between both “add” and “edit” operations. I believe you'll need to request this as a feature or modify the code yourself….

The “editGridRow” function handles both add and edit operations. You might want to see the “grid.formedit.js”

Note: This is for form editing..

Ok, I think it is not completely correct share the same logic for add and edit, because there could be different behaviours, not only the HTTP operation type.

By the way, Is there a way to force the HTTP operation in the “beforeSubmit” event, respectively of add end edit options?

Thanks

June 27, 2011 at 11:45 am in reply to: Error event in form editing #98338

r.cappa
Participant

I've solved with “errorTextFormat” options.

June 24, 2011 at 11:45 pm in reply to: Error event in form editing #98328

r.cappa
Participant

tony said:

Hello,

You can use

June 20, 2011 at 9:56 am in reply to: Problem with search toolbar and name!=index in colmodel #98298

r.cappa
Participant

r.cappa said:

tony said:

Hello,

This is not a bug. First we try to use the index and then the name.

Regards

Tony

Ok, but if both name and index are specified, nothing is sent to the server…

thanks

Sorry, only in 4.0.0 there was this problem, in 4.0.1 It works. Thanks.

June 18, 2011 at 4:21 pm in reply to: Problem with search toolbar and name!=index in colmodel #98293

r.cappa
Participant

tony said:

Hello,

This is not a bug. First we try to use the index and then the name.

Regards

Tony

Ok, but if both name and index are specified, nothing is sent to the server…

thanks

June 17, 2011 at 9:38 pm in reply to: Problem with search toolbar and name!=index in colmodel #98283

r.cappa
Participant

Hi, it seems to be an unresolved bug also in 4.1.0. Is it planned to fix it in next versions? Thanks

June 16, 2011 at 12:05 am in reply to: There’s a filterToolbar bug when the name and index are different #98250

r.cappa
Participant

It could be related to this…?

Forum

June 14, 2011 at 11:15 pm in reply to: Bug in form editing: checkbox #98239

r.cappa
Participant

I think the problem is at line 5075, the instruction setAttributes(elem, options); seems to be executed before the preceding if, at line 5055
Author

Replies

Viewing 15 replies - 1 through 15 (of 16 total)

1 2 →