|
I have a ASP.net application written in VB.Net which is the main application. I have another ASP.net application written in C#. I want to integrate the C# project files into the VB.net project ( without having to convert C# code to VB.net ) . The C# project contains few aspx pages and couple of C# utility classes.
What would be the best way to integrate the C# files into VB.net project and run these successfully within the ASP.net app?
Thanks
Madhuri Mittal
|
|
|
|
|
|
Hi
I need component for embedding to my .NET application for WinXP (Tablet PC Edition). This component must can draw graphic primitives (lines, rectangles and other, for drawing simple plan of houses) maybe like MS Visio, but more simple  .
Can you recommend components for this?
thanks
|
|
|
|
|
Two simple questions:
1. Why "__property"? What does it offer that regular "method" does not?
2. When instantiating managed class..
SomeClass MyInstance; (illegal, if "SomeClass" is a managed class.
SomeClass* pInstance = new SomeClass (legal)
Why did they design it as such? Is there any purpose behind this?
Here's a short code to illustrate the point:
__gc class Dummer
{
protected:
int m_nValue;
//Keep track of how many times a propert has been accessed.
int nCountRead;
int nCountWrite;
public:
Dummer() { nCountRead=0; nCountWrite=0; }
//Property - public. But what's the use exactly? How's this different from a member function?
__property int get_Val()
{
nCountRead++;
return m_nValue;
}
__property int set_Val(int nVal)
{
nCountWrite++;
m_nValue=nVal;
return 1;
}
};
// This is the entry point for this application
int _tmain(void)
{
// TODO: Please replace the sample code below with your own.
Console::WriteLine(S"Hello World");
//QUESTION 1: What's the purpose of "__property"?? What's the difference between "__propery" and "method"??
Dummer * Tom = new Dummer;
Console::WriteLine(Tom->get_Val());
//QUESTION 2: Error C3149 here. You must declared John as a "pointer" - but why did the .NET team assert that all managed class instance must be "pointer" to the class at hand??
/*
Dummer John;
John.m_nValue = 10;
*/
return 0;
}
norm
|
|
|
|
|
norm wrote:
2. When instantiating managed class..
SomeClass MyInstance; (illegal, if "SomeClass" is a managed class.
SomeClass* pInstance = new SomeClass (legal)
Why did they design it as such? Is there any purpose behind this?
It just makes object instantiation more consistant across .NET languages.
norm wrote:
//QUESTION 1: What's the purpose of "__property"?? What's the difference between "__propery" and "method"??
Dummer * Tom = new Dummer;
Console::WriteLine(Tom->get_Val());
Actually a property is referenced slightly different, and similar to field access. You would call:
Dummer * Tom = new Dummer();
Console::WriteLine(Tom->Val);
norm wrote:
//QUESTION 2: Error C3149 here. You must declared John as a "pointer" - but why did the .NET team assert that all managed class instance must be "pointer" to the class at hand??
/*
Dummer John;
John.m_nValue = 10;
*/
return 0;
}
Declare the type as a __gc struct. Then behaviour is like a struct, but it can contain members. You can look into __value types too, AFAIK these are allocated on the C++ heap and not the .NET heap, and hence are accessable from both.
leppie::AllocCPArticle(Generic DFA State Machine for .NET);
|
|
|
|
|
norm wrote:
1. Why "__property"? What does it offer that regular "method" does not?
I am not a fan of properties myself - I think that a function should have a syntax of a function, but anyway in .NET all accessor methods should be implemented as properties. Just learn to live with it
norm wrote:
2. When instantiating managed class..
SomeClass MyInstance; (illegal, if "SomeClass" is a managed class.
SomeClass* pInstance = new SomeClass (legal)
Why did they design it as such? Is there any purpose behind this?
Because in C++ the first version would create MyInstance on stack, and gc objects can go only to managed heap.
|
|
|
|
|
Nemanja Trifunovic wrote:
I am not a fan of properties myself - I think that a function should have a syntax of a function, but anyway in .NET all accessor methods should be implemented as properties. Just learn to live with it
It has a number of benefits. For instance, if you wanted to increment a value by 1, with a property you could do this:
Object.Property++;
rather than
Object.setProperty(Object.getProperty()+1);
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Yes it is easier to type
However, properties's syntax hide the fact that they are functions, not data members, and I don't like it. In ideal world nobody would use public data members and then I wouldn't mind. However, too many people use public members, and sometimes it is not obvious whether
Person.Name = "Joe";
refers to property or member data.
|
|
|
|
|
Yeah, that's true. The guidelines I go by are: If it's essentially going to set some member data and then do some things that should be done when that value changes, then it should be declared as a property. But if it's going to do more than that - say, setting some value outside of the class it's in, then it should be a method. I also noticed that a number of the framework classes go by this rule, too.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
__gc class A
{
protected:
String* m_sobj_name;
int m_nCountRead;
...
...
public:
__property String* get_name() {
m_nCountRead++; //Keep count.
bArth=Authorize(); //Do other stuff.
if(bArth==false) {return "error";}
return m_sobj_name; //Then, return protected property in the end.
}
...
...
};
_tmain(..)
{
...
A *pObj = new A;
String* sName = pObj->name; //simpler syntax, yes.
};
norm
|
|
|
|
|
Where can I find it?
--------
"I get to go to lots of overseas places, like Canada."
- Britney Spears, Pop Singer
|
|
|
|
|
|
|
I am paitently waiting for Microsoft to release SP1 of 1.1 to resolve the following issue (the host won't install the hotfix until it is part of a service pack)...
http://support.microsoft.com/default.aspx?scid=kb;en-us;818803[^]
Any idea when the service pack is planned?
David Wulff
"Yeah, ohh, ahh. That's how it always starts. But then later there's running, and screaming."
-- Jeff Goldblum, The Lost World.
|
|
|
|
|
9rays.net Report Sharp-Shooter 1.3 has been published!
Report Sharp-Shooter is the most flexible .NET report engine available on
the market. It's a suite of 100% managed .NET components that allow you to
create both bound and unbound reports with unlimited number of master-detail
relations. You can build highly complex reports by using groups, columns,
crosses, double pass mode, C#/VB scripting etc. Full data-binding model is
supported with all .NET sources.
Package includes royalty free runtime designer for ready documents and
report-templates.
The professional version comes with the source code.
Visit us at www.9rays.net for more info.
Best regard,
Eugene
|
|
|
|
|
I have some problems whith the splitters. In design time it's O.K. But the problems start at runtime, when I create some child Forms by code and I try to dock them inside a new splitter but it's impossible, the splitter ignores the correct order (it´ss been generated later than the Form child) and does not include the new child form inside. It's like the Form child is not treated like another design control inside the main Form.
Please, can anybody help me about the treatment and placement of splitters controls in run time with Windows Forms?
Thank you.
Raf.
|
|
|
|
|
I have some problems whith the splitters. In design time it's O.K. But the problems start at runtime, when I create some child Forms by code and I try to dock them inside a new splitter but it's impossible, the splitter ignores the correct order (it´ss been generated later than the Form child) and does not include the new child form inside. It's like the Form child is not treated like another design control inside the main Form.
Please, can anybody help me about the treatment and placement of splitters controls in run time with Windows Forms?
Thank you.
Raf.
|
|
|
|
|
Why does a simple .NET app with a few forms take more memory to run than apps like explorer.exe and wmplayer? Furthermore, why after closing a form does a .NET app not release the memory used by that form? For extended runtime apps this could pose to be a serious issue. Are there any tips you all could offer on memory management in .NET to make it more efficient?
-- Adam
"If you can't beat your computer in chess, try kickboxing"
|
|
|
|
|
The same reason its such a processor hog, its interpreted.
I'm sure that the garbage collection system will eventually release the memory.
I haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise.
|
|
|
|
|
What do you mean by its interpreted?
Bo Hunter
|
|
|
|
|
I mean that the CLR converts IL to x86 machine code at runtime.
|
|
|
|
|
That's not quite the same - an interpereted language is never compiled at any point, whereas Java and MSIL are compiled to native code at runtime, and can even be turned into a native code exe using ngen.exe .
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
I see. The processor uses esp to sense which instructions to perform from an interpreted language...
Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
|
|
|
|
|
No, it parses the code and calls predefined methods based on the code.
But even if it compiled it (which no doubt some interpreters do), there is a huge difference between parsing text code and reading byte code.
You can also easily create a native image from an assembly, which is just a cached native code image of the assembly, and does not need to be JITed.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Joey Bloggs wrote:
Interpreted / JIT it is about the same performance hit
When code is JIT compiled, it will be compiled only once during the execution of the program, regardless of how many times the same code is run (in loops etc.)
In interpreted code, the interpretation process is repeated for each loop iteration.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
