|
Hi All,
I am currently working with web services and while sending data to web service i am getting this Error:
"The request failed with HTTP status 400: Bad Request"
Can anyone tell me why i am getting this Errr ... 
Regards,
Perry
|
|
|
|
|
See this[^] answer. Not very helpful, I'm afraid, but that's how it is...
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
I'm using the
decimal for group totals in an application that exports financial data. The only calculation done on the total is accumulation; no multiplication, division, tax etc. In my output, I get a decimal total value of '13135984.162500000001985789145', where if I load the export file in Ecel and sum the values, none of which have beyond four decimal points with no explicit rounding, I get the same total as the control file I am comparing my export file to: '13135984.1625'.<br />
<br />
<br />
<br />
<div style="display:none;" class="CPhogPost"></div> <br />
<br />
<div class="ForumSig">Semicolons: The number one seller of ostomy bags world wide. - dan neely</div>
|
|
|
|
|
Anywhere in there that you cast to double? 29 precision looks like it has been converted to double somewhere.
|
|
|
|
|
I can't find anything. The only double I used in the whole project is in my PercentComplete event, totally unrelated to the totals. I'll have to go and sniff out what the database is returning.
Semicolons: The number one seller of ostomy bags world wide. - dan neely
|
|
|
|
|
How are any numerical constants specified? The default format for numerical constants is double, so if you take your "decimal" number and add 1.3 to it, you'll really be adding something that isn't quite 1.3 and the "decimal" will capture that imprecision.
|
|
|
|
|
There are no constants, but I'm going to look at the data type carried in from SQL Server. It looks to be decimal for money fields, but their may be are 'money' fields that are not money but float, which the CLR converts to doubles.
Semicolons: The number one seller of ostomy bags world wide. - dan neely
|
|
|
|
|
We're developing a new application framework and need to implement a script host so custom logic can be added at several places in the application. As a test, I put in the IronPython script host and it worked well. However, I'd rather use a language like JScript/JavaScript because it is a little more common. I have read that the DLR will support JScript eventually, but only IronPython by the end of the year.
We really need to be able to run these scripts in a sandbox environment, giving the script host access to the objects and methods that we want the users to have.
Does anyone know of a great script hosting solution for .Net?
|
|
|
|
|
You can execute script using ActiveScript technology. It works. Another great thing with this, WinForm components properties can be accessed like if they were ActiveX. Page me directly if you need to know more about this.
1. I will develop myself to the maximum of my potential in all ways
2. I will look for the good in all people and make them feel worthwhile.
3. If I have nothing good to say about a person, I will say nothing.
4. I will always be as enthusiastic about the success of others as I am about my own.
5. I will always remain loyal to God, my country, family and my friends - Chuck Norris
Ernest Laurentin
|
|
|
|
|
You can always use PowerShell extensions. It is very powerful, but not so intuitive.
|
|
|
|
|
Hi,
I am implementing PC Charge payment server using PSCharge.dll (ver 4.3.0.0) it some times shows transaction canceled but again immediate after that transaction processed. Why the error is coming first time. Is this version not compatible to asp.net2.0.
Thanks in Advance.....
Regards
Sandip
|
|
|
|
|
Hello All,
I had written a piece of code for working with the BackgroundWorker.Following is the code for the same:
BackgroundWorker ^ defReportWorker = gcnew BackgroundWorker();
defReportWorker->WorkerReportsProgress = true;
defReportWorker->WorkerSupportsCancellation = true;
defReportWorker->DoWork += gcnew DoWorkEventHandler(this, &Form1::GenerateDefaultReport);
defReportWorker->ProgressChanged += gcnew ProgressChangedEventHandler(this, &Form1::updateProgress);
defReportWorker->RunWorkerCompleted += gcnew RunWorkerCompletedEventHandler(this, &Form1::DefEndWorker);
GenerateDefaultReport is the function which i need to execute
DefEndWorker is the function which will be called upon completion of the GenerateDefaultReport function.
The client was a german client and we were developing the code on the german OS machines in our company. The problem we faced in this code was that the function "GenerateDefaultReport" was not called when the code compiled on the German OS machine was executed on the English OS machine. but the code compiled on the English OS machine was executing properly and the said function was called on the German OS machine.
German compiled - german execution - running
German compiled - English execution - not running
English compiled - English execution - running
English compiled - german execution - running.
Can any one please help in this?
|
|
|
|
|
Don't cross post
led mike
|
|
|
|
|
This isnt cross post. Its related to .Net Framework and its working.
If you can't help then please do not write one liners which reach the dead end.
Is the behaviour of BackGroundWorker is different for the different regional languages?
This is the question and the would appreciate if any answers are received.
|
|
|
|
|
antariksh wrote: This isnt cross post.
Cross Post means you posted the same question in more than one forum, which you did so it IS A CROSS POST.
led mike
|
|
|
|
|
Ok. Now it is not a cross post. A help will be more appreciated. 
I have also checked the problem with other developers in my offline network, but couldnt get the reason for the same. All of us are stumped as to why the executable doesnt execute the function. I shall just give a glimpse of the situation again.
A German language OS compiled code does not transfer the control to GenDefaultReport function in the BackgroundWorker thread, when the code is executed on the English language OS. The more detailed description is mentioned at the start of thread.
|
|
|
|
|
antariksh wrote: Is the behaviour of BackGroundWorker is different for the different regional languages?
This is the question
Well I've never heard of that but I have never done any development using the different OS versions. Here are some obvious questions you likely have already investigated:
How do you know it's not called?
Have you stepped through the code in an environment where it doesn't work?
Is there a flow of control bypassing the call that might flow different due to the language? Like checking a Date or string or something not implemented with proper internationalization approachs?
led mike
|
|
|
|
|
->How do you know it's not called?
I had written some message boxes at the called function start and also was creating a log file for all the functions being called.
->Have you stepped through the code in an environment where it doesn't work?
Yes i have debugged the code in both the environments, but didnt get the reason.So am asking here in the forum.
->Is there a flow of control bypassing the call that might flow different due to the language? Like ->checking a Date or string or something not implemented with proper internationalization approachs?
There is no flow control statement.
Can you please ask your co-developers about the problem.I have also asked developers other than my company, and even they haven't heard of this behavior. The solution was to just re-compile the code in English OS. 
|
|
|
|
|
In .NET 2.0 great strives have been made to make binary serialization more version tolerant, with new or removed fields no longer throwing exceptions. Although one scenario that keeps throwing an exception... when the type of a field has changed. Using OptionalFieldAttribute one can indicate to omit during deserialization a new field, if the data for that field is not present in the old stream.
Is there any declarative (such as TypeConverterAttribute) or imperative mechanism to handle situations when the type of the field has changed, to prevent exception from throwing when data type of one or more fields has changed? Essentially to ignore reading data for fields that have different type between definition in old serialized stream and new definition in assembly.
Thanks in advance
Deviation from good code design leads to the dark side (aka kludgy code).
Mike M
MCAD.NET
WinInsider.com - News for Microsoftonians
|
|
|
|
|
Not sure if such attribute exists. If one does not exist, you can write your own.
Or you can catch the exception during the Deserializing event which is raised before deserialization. You can use the attribute:
[OnSerializing]
void TypeHasChanged()
{
//Handle type change exception
}
|
|
|
|
|
Why does <code>DateTime.ToShortDateString()</code> not use the system short date format? Surely that is the format you would want if you don't wish to override the default formatting?
Semicolons: The number one seller of ostomy bags world wide. - dan neely
|
|
|
|
|
I think it does for me.....
Christian Graus
Please read this if you don't understand the answer I've given you
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
I had a bad brain day yesterday. I just checked again all works fine.
|
|
|
|
|
I am currently working on deploying a .NET component (Windows Form - UserControl) for use [embedded] in Internet Explorer.
The actual delivery system is this:
I have a deployment project that packages everything as an *.msi
This *.msi + an *.inf are packaged in a CAB file, which is referenced in the CODEBASE attribute of the object tag in the markup.
This part is great - it is deployed, installed, & works fine.
What I am dealing with now is the upgrade process.. From all of my research & trials, which can more or less be neatly summed up on this page.. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1536629&SiteID=1[^]
Since mscoree.dll is what has to instantiate the object for IE to host it, when msiexec installs my component, everything is installed referencing the .NET2.0 version, 2.0.50727.1433. So, for IE to be able to hook into the code base & install it properly, I have to append the version information (to the codebase attribute) as 2.0.50728. This is obviously sub-optimal, and presents the need for a potentially ugly workaround.
Per some of the articles/posts I have read, I have fiddled with registry values in the following keys, but to no avail.
HKEY_CLASSES_ROOT\CLSID\{...}\InprocServer32
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Code Store Database\Distribution Units\{...}
If anyone has had to deal with a similar case, or has any ideas on what to try, I would definitely appreciate the help!
Thanks -
|
|
|
|
|
And if they can be, how? Can't any other less space-taking program/environment take its place? And why?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
