Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #1 
Numeric fields default to 0 on load but I have been asked to change this behaviour.

I have tried

setField("MyField","","");


And it works great for the very first numeric field on my form.

Then for all others, when I load the form I get "Incorrect format of input string".

Baffled as to why it would work for 1 numeric field and not the rest.

Anyone got any sneaky tricks to suppress that default 0?
0
totaldis

New Member
Registered:
Posts: 9
Reply with quote  #2 
I can't explain why the first field is working for you, but I can tell you that the default value of a .NET type INT is 0. Since, as far as I can tell, Metastorm does not use nullable types, there is no way around this without some client side trickery.

...aaron
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #3 
.Net on the client side?
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #4 
So here was my plan. Superimpose a text box over the numeric field. Add an input mask like

^[0-9]?[0-9]?[0-9]?[0-9]?[0-9]$


So as to have a variable length numeric up to 5 digits long, for example.

Then in the Field exit event, set the value of the numeric field behind the text box, thus

var myTextboxValue = getField("MyTextBox");

if (myTextboxValue =="")
{

setField("MyNumericField","",0);

}

else

{

setField("MyNumericField","",myTextboxValue);

}


This works ok "sometimes" and sometimes not.

When it doesn't work I get the error "Input string was not in a valid format".

It's a 50/50 as to whether it works or not, and as such the whole form is now unstable and it is affecting other client side events.

0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #5 
Additional information. I added the following line

alert (typeof(myTextboxValue));


just above the line

setField("MyNumericField","",myTextboxValue);


And discovered that when it breaks, myTextboxValue is of type [object].

So it would seem that getField sometimes returns string, and sometimes returns object and this is what is giving me the 50/50 behaviour.

I'm going to add a test (nested if) to handle the object type and see if this redundancy gives me a more robust form.
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #6 
My recommendation (having had to deal with the issue): Manage User Expectations.

Sorry, but a number field always has a number in, regardless.

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #7 
Sadly on this gig I'm not in control of the specification, nor do I have access to the end user community. I'm just the hired hand and have to code to spec. I've pushed back politely, and suggested the business analyst in question better understands the Metastorm form designer before writing specs in future, but to push it any further would be counterproductive.

I am, as they say, stuck between a rock and a hard place.

Why do you think my solution will not work?

I think I've found a nasty with the telerik controls in that the getField method uses find$ to locate the control and then calls get_value(). Seemingly on a 50/50 coin toss this method returns an object rather than a string.

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #8 
Quote:
Originally Posted by suityou01
Why do you think my solution will not work?


Because the behavior of these controls is not supported or guaranteed by Metastorm (at least as far as I know), and will change at some point. It always has up to now!

I do understand your dilemma, but you should inform the customer of the risks. We are upgrading one particular system now, and the customer seems completely unaware that functionality relying on hacks was never supported and just will not fly in the new version.

My only advice is never to hack, and if you must, make sure the risks are fully documented.

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #9 
Well if my custom title of "Veteran" on here is anything to go by, I would already know this. I've been working in IT for a long time and I am not some "hacker". In any case, using the getField and setField javascript functions is not hacking, and these functions have been around since I can remember in E-Work 5, so I can't see them being dropped any time soon. Since the switch to Telerik controls I have spotted some anomalies such as the one I mentioned in post #5.

An alternative approach I am trialling is to use only text boxes with input masks, assigning the values to local text variables, and then using an assignment activity to cast them to Ints and pass them to the process variables.

I will let you know how this goes.
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #10 
So I used text fields. I used an input mask of

^[0-9]?[0-9]?[0-9]?[0-9]?[0-9]$


for example which will mask anything from 0 to 99999.

If you enter an alpha character, or an extra digit, then you get a little yellow triangle at the end of the text box to inform you that the input string deviates from the mask.

Then in the form exit I use an assignment activity to assign the corresponding value to the numeric variable on my process business object.

Convert.ToInt16((this..txtMyMaskedField.ToString()==""?"0":this.txtMyMaskedField.ToString()));


It is stable enough for me to happily submit into SIT.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!