|
Sassan Komeili Zadeh wrote:
- Is TAPI supported in .NET?
Sadly not yet. Your best bet is using COM interop with the TAPI 3 COM interfaces. I had a brief attempt at using TAPI 2 and Managed C++ but it was more trouble than it was worth. In the end I wrapped my TAPI 2 code in a COM object.
Michael
The avalanche has started, it's too late for the pebbles to vote.
|
|
|
|
|
Hello all.
I have VS.NET (Production) installed on my machine now. What is the "fall-out"  of installing VS.NET 2003 Final Beta on the same machine?
TIA.
Don
|
|
|
|
|
|
I know this is properly the dummest question? But still I want to know, recently I am been assigned to devlope a program in Apple Mac OS (a program that has to interact with Excel - how do u do that? there isn't OBDC in Apple).
Anyway, I was wonder can program that written in C# or VB .NET work in Apple Mac. can it??
(Sorry for wasting space, time, in reading this real stupid question)
If there are three people walking with me, one of them can be my teacher.
[Andy]
|
|
|
|
|
|
Thanks, I am going to check now...
If there are three people walking with me, one of them can be my teacher.
[Andy]
|
|
|
|
|
If you're app is commercial (at least according to the terms of the SSCLI licence) then you cannot build it with that framework (Microsoft's SSCLI that runs on FreeBSD). That's not too big a deal, though, because the SSCLI doesn't support any of the System.Windows.Forms namespace - all you can do is write console apps.
--
Russell Morris
"Have you gone mad Frink? Put down that science pole!"
|
|
|
|
|
After, I checked FreeBSD, it isn't what I really need. So, What kind of software should I use???
That will allow C++ to interact with Excel in Apple Mac?
If there are three people walking with me, one of them can be my teacher.
[Andy]
|
|
|
|
|
Hi all,
I was wondering if anyone out there could point me towards a good business-focussed discussion of the benefits and pitfalls of developing Windows software, particularly database-centric client/server and n-tier systems, in .NET.
Bit of a wish, but any suggestion appreciated.
|
|
|
|
|
Dunno of any specific discussions apart from those on CP. From what angle are you asking ?
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Hiya Christian,
I work at a company that builds a Windows POS product. To date we've used MFC and in the Dark Ages Borland OWL, but now that .NET has appeared on the scene it appears to be a good candidate for the development of some new and significantly large features we're taking on, not least because of the speed of developing user interfaces, easy memory management, and because we're looking for an alternative database access technology to the outdated BDE, making ADO.NET an attractive candidate.
As we move towards an enterprise solution that includes non-POS clients we're considering a more tiered architecture with one or more business object layers. We've done a bit of this with COM already, but also want to consider using .NET objects because of the relative ease of development and apparently flatter learning curve for new developers.
Our other choices for moving forward are to stick with MFC, COM/DCOM and probably OLEDB, all good technologies but falling steadily behind the main MS push, I feel.
Anyhow, I've got a week to present a summary analysis of the potential use of .NET technologies in our products... When it comes to supporting a decision either way, it looks like my task is a bit harder than I first thought 
Thanks for the reply (ps, do I remember rightly that you're also hangin' here in sunny Brisbane?)
|
|
|
|
|
Choosing .NET is a matter of application need you have. I would choose .NET in the long run if the application does not really need high performance (GC is a show stopper, lot of memory overhead), and has a strong web exposure (ASP.NET).
Choosing .NET is not a matter of underlying technologies such as COM, etc. since .NET supports them as well (both ways).
|
|
|
|
|
I can tell you from experience use .NET, if you don't want to take my word for it, go to www.microsoft.com/net[^] you'll find plenty of info.
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
I have written a class that exposes a Stream (.NET) object through an
IStream (COM)implementation:
public class OleStream : IStream, IDisposable
{
....
}
I use this class to publish one or more files on the clipboard in the
FileGroupDescriptor/FileContents formats (to do this, I have to put a
pointer to a IStream interface in the pstm member of the STGMEDIUM
structure).
Everything is working fine, except the closing of the .NET base
stream. The problem is that I don't know when the OleStream is
released so that I can close the .NET base stream. I can of course
close the base stream in the Finalizer of the object, but then I have
to wait for the Garbage Collector; I want to close the Stream as soon
as possible.
My question is: How can I know when the OleStream is released?
Corne Los
|
|
|
|
|
... or that I'm being thick.
I've just read the list of breaking changes for v1.1 of the framework: http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/[^]
There's nothing too bad, until you get to http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx#00000139[^]:
Calling a method through a Delegate performs the same accessibility checks as calling that method directly
Description: The common language runtime allows method C.MethC() to call method A.MethA() only if A.MethA() is both visible and accessible to the caller.
In particular, if A.MethA() has accessibility "protected", then the call will only succeed if class C is derived from class A.
However, this check was skipped when the call was performed through a Delegate. This bug has now been fixed so that calling a method either directly or through a Delegate follows the same rules for visibility and accessibility.
Workaround: Change the accessibility of the target method so that it is legitimately accessible to the caller.
As I read it, this means that: - every event handler;
- every AsyncCallback method;
- every ThreadStart and WaitCallback method;
- every utility class used to pass state to a thread;
- etc...
has to be made public, since the code which invokes the method is in a different assembly, and is not derived from your class.  
For example, instead of:
public class SimpleForm : Form
{
private TextBox _textbox;
...
private void textbox_TextChanged(object sender, EventArgs e)
{
}
public string TheText
{
get { return _textbox.Text; }
}
}you now need:
public class SimpleForm : Form
{
private TextBox _textbox;
...
public void textbox_TextChanged(object sender, EventArgs e)
{
if ( ... )
{
}
}
public string TheText
{
get { return _textbox.Text; }
}
}
I don't claim to be an OO expert, but this seems to throw out the concept of encapsulation. The public interface of your class will be clogged up with event handlers for private objects, callbacks for threads and asynchronous operations, etc. Not to mention the fact that this will break all non-trivial version 1 apps, since these methods are usually declared as private or protected.
If anyone from Microsoft is reading this, or anyone has used v1.1, please tell me I'm seeing things and that this "fix" doesn't mean what it sounds like it means. Because if it does, I don't think I'll be upgrading. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
|
|
|
|
|
hmmmm....I think what that means is that before you could do
<br />
class A<br />
{<br />
protected void B();<br />
}<br />
<br />
class C<br />
{<br />
public void D()<br />
{<br />
A a = new A();<br />
Delegate del = new Delegate(a.B);<br />
del();<br />
}<br />
<br />
public void E()<br />
{<br />
A a = new A();<br />
a.B();<br />
}<br />
}<br />
<br />
I guess what the bug fixes is that you can effictively call A.B() even though it is not accessible via delegates.
I sure hope that's what it means 
May the Source be with you
Sonork ID 100.9997 sijinjoseph
|
|
|
|
|
Nope. I already tried that, and v1 generates a compiler error:
error CS0122: 'A.B()' is inaccessible due to its protection level So unless this "bug" was fixed by v1 SP2, that's not what they mean.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
|
|
|
|
|
Apparently, the bug is with the static CreateDelegate method, which ignores the protection and visibility of the target. The fix doesn't require the method to be visible to the code which invokes the delegate, just the code that creates it.
This code will compile under v1, but not v1.1:
public delegate void TestDelegate();
class A
{
protected void B()
{
Console.WriteLine("Hello from A.B!");
}
}
class C
{
static void Main()
{
A a = new A();
Delegate del = Delegate.CreateDelegate(typeof(TestDelegate), a, "B");
del.DynamicInvoke(new object[] {});
}
}Thanks to Emil for pointing this out on the GotDotNet forum:
http://www.gotdotnet.com/Community/MessageBoard/Thread.aspx?id=66891&Page=1#66978[^]
Looks like I will be upgrading after all!  
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
|
|
|
|
|
hi ,
i have created a software in VB.Net.
can anybody plz help me how to deploy it so that it can run under WINDOWS NT 4.0.
i specially want that software to be deployed and run under Windows NT 4.0
thnx
Aakash.
|
|
|
|
|
Hey Aakash,
If your application is VB.NET Webform based, running on Windows NT series is simply impossible. It is out of question. Perhaps since, as far as I know, IIS/PWS on Windows NT can not process ASP.NET pages. The minimum criteria is Windows 2000.
Well! All Client Applications in C#/VB.NET would function in Windows NT. Package your VB.NET file as an MSI using Setup and Deployment project and you can deploy this on Windows NT workstation. One more thing: You may need to have Microsoft.NET Runtime to run the application. .NET Runtime is ~20 MB in downloadable size from Microsoft.
This should facilitate running of your VB.NET application on Windows NT. You may not need 132 MB .NET SDK over there if you are not going to do any development and the 20 MB runtime should do.
Did this solve your query?
Deepak Kumar Vasudevan
http://deepak.portland.co.uk/
|
|
|
|
|
Hi,
I want to know whether it is possible to handle events raised by COM components in a windows service developed in .NET using VisualC#.NET . if it's possible, can someone explain me the way to do it? The component under question is an ATL component.
Thanking you in advance.
Thanks
Desai
|
|
|
|
|
Yes, it's possible even though there are several pieces to put together before you get anything working.
Subscribing for COM events using .NET is much like with standard C/C++ code : you request IConnectionPointContainer provided by the COM component, then enumerate all IConnectionPoint(s), sink those which are interesting, and your interface methods will be automatically called then.
For ready code snippets to play with, look up this site and the MSDN support KB with this keyword : UCOMIConnectionPointContainer. Here is an example[^].
|
|
|
|
|
hello
how would i write a game using .net to put on the internet
the sort of thing you could do using java applets
thanks
joe
|
|
|
|
|
|
Hi all,
I deployed a private assembly (non-signed) then later (signed) to a strong-named assembly using Assembly.Loadfrom with a URL. When I encounter Interop assemblies I was getting:
The assembly gets downloaded, but complains, WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
All my assemblies are signged and imported references to introps assemblies are wrapped with the key file. Everything checks out in the manifest, etc.
But the problem lies with IE. It seems to have cached the old assembly, and never re-loaded. So clearing my IE cache, fixed the problem.
This seems like a bug to me. Since the new strong name assembly should have replaced anything it was being compared to. Very strange.
Anyway -- if anyone has an comments or experience, I'd welcome it.
Ingram Leedy
You can't depend on your eyes when your imagination is out of focus.
--Mark TwainURL file:///C:/Program Files/ElephantBackup/Client/AxInterop.SHDocVw/AxInterop.SHDocVw.EXE.
LOG: Attempting download of new URL http://192.168.1.31/Client/AxInterop.SHDocVw.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Documents and Settings\Leedy\Local Settings\Temporary Internet Files\Content.IE5\P8KFPLGP\AxInterop.SHDocVw[1].DLL
LOG: Entering download cache setup phase.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: The assembly reference did not match the assembly definition found.
ERR: Setup failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Ingram Leedy
You can't depend on your eyes when your imagination is out of focus.
--Mark Twain
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
