|
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?
|
|
|
|
|
Wajeeha wrote: Why can't .Net executable programs work on a system without .Net framework?
Because the framework contains the code that your application calls. Unless you write an application that makes zero calls into the framework. But even then it requires the CLR.
Wajeeha wrote: And if they can be, how?
There are third party tools that encorporate what is needed into your application, but they are very expensive.
Wajeeha wrote: Can't any other less space-taking program/environment take its place?
At the end of the day you have to consider what your priorities are. If you require a small footprint then you have to design to that consideration from the start.
If you have already gone down the road of building the .NET application then you are probably stuck with that descision.
Wajeeha wrote: And why?
Why what? I don't understand "why" in this context.
|
|
|
|
|
Microsoft Research have a compiler called Pheonix that can do a little bit of everything (eg compile all of the languages that MS support).
It has been discussed to make it able to compile to native too.
So it's not impossible that we will see a C# to native compiler from MS in the future..
|
|
|
|
|
Roger Alsing wrote: Pheonix
Is the one you are referring to?
http://research.microsoft.com/phoenix/[^]
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Yes
There is an interesting clip about it here:
http://channel9.msdn.com/Showpost.aspx?postid=396461
|
|
|
|
|
Wajeeha wrote: Can't any other less space-taking program/environment take its place?
I suggest you upgrade your 120MB hard drive.
|
|
|
|
|
Their are open-source 'wrappers' for the .NET framework that allow .NET applications (up to 2.0 as of right now) on other OSs such as linux, mac, and unix.
A few to mention:
Mono
Portable .NET
Read about them at: Wiki article on .NET Framework[^]
Regards,
Thomas Stockwell
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Visit my homepage Oracle Studios
Discounted or Free Software for Students:
DreamSpark - downloads.channel8.msdn.com
MSDN Academic Alliance - www.msdnaa.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
