|
sweet.
Thanks for the info. I knew I had to do a hook, just wasnt sure exactly what to implement.
Steve Welborn
Software Architect
|
|
|
|
|
i've a stream .avi file, how can i play it in a picturebox control?
|
|
|
|
|
You don't. You play it in a MediaPlayer control. If your using VS2005, it's alreayd in the toolbox. If not, you'll have to add it to the ToolBox. Right-Click the Toolbox window and select Add/Remove Items. Click on the COM tab in the dialog that pops up. Scroll down the list until you find Windows Media Player, then check the box next to it. Click OK.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Hi. I'm writing a desktop application. I have 6+ years of C++ / MFC, so I started off writing it in MFC/C++. I'm considering switching it to Winforms & C#, as I can see I might have a future need for mobile/web development, and I don't want to lock into an older technology that Microsoft doesn't seem too keen on enhancing in the future (i.e. MFC)
If I do move the app, I'd take the full plunge and re-write the whole dang thing in C#, so I'm not concerned about any interop (etc) issues. I've read a C# book, and the language seems straightforward for me, given my C++ experience, so I'm not worried about the language itself.
I'd like to hear some advice on:
1) WinForms/C# - how is the UI programming experience (I'd especially like to hear, if you have extensive MFC experience)? e.g. How does using purchased components, or writing custom controls compare with MFC? I've read "you must be on crack to even consider MFC in 2005" in a few message boards, but I've yet to be convinced - would you agree with this?
2) WinForms/C# - what do you think the prospects are with regard to the new Vista UI (i.e. is XAML going to kill off support for WinForms)? Should I just stick with MFC for now, and then move it over to XAML in a number of years ???
3) If I do go for it, I plan to buy a lot of the UI components - can anyone recommend some UI suites (e.g. Infragistics). I'm looking for: a good extensible "grid", VS2005 style docking windows, a VS2003+ property grid, and a report control.
Any advice would be very much appreciated...
Warren Stevens
|
|
|
|
|
1. I still think MFC is a viable platform, but Winforms is definately easier, and at least as easy to write custom controls for. At the end of the day, you can access the underlying message loop, you can call any C++ API via interop, so I doubt there's anything you can't do.
2. XAML is not going to kill Winforms IMO. For starters, you can only ship WinFX to XP, 2003 or Vista. Until there is no need to support W98 or W2000, WinFX seems to me to be a sleeper technology.
3. The grid in Winforms is fine, no need to buy. I don't know of any control libraries, because I've never used one.
If you're going to switch to C#, can you wait a few weeks and buy VS2005 ? C# 2.0 is awesome.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I made the switch from MFC/C++ a while back and haven't regretted it once.
I've written a few bits on my blog about the experience. You can read the entries here[^]
Michael
CP Blog [^] Development Blog [^]
|
|
|
|
|
Hi, Warren!
Sorry to bring up this 6 month old post  , but about the time of your post I was working on certain ...Prop application (you might recall that old project). It is a desktop app and was written initially in .NET Managed C++ by someone else. My task was to "fix it up" and I had two month (with lots of overtime) to do it. Well, it wasn't well written to begin with, so I ended up almost rewriting the whole thing.
The experience was very unpleasant.
1. Working with WinForms resources VS2003 is horrible. And why aren't the sizes and coordinates relative like with MFC/Win32? Absolute pixel coordinates is a horrible idea! I pulled lots of hair trying to get some of the controls to look properly on different monitor resolution.
2. With MFC you got all the source code so you can get down and dirty and customize some controls to behave and look just the way you want it. Not with .NET controls! Customizing certain controls was also a great pain.
3. If you use Interop, browser control, and third party controls (which you would in most professional desktop apps) you end up with gazillion dlls that have to be shipped with your executable.
4. Cannot run .NET app off the network. There are workarounds, but they are so complicated and all have to be done on client side by the person installing your app. Just reading these workarounds I got a feeling that you ahve to be an IT pro to do it.
5. Code protection. Basically you are giving awya your source code with every app that you ship to your customer. Sure you can try obfuscating, but that doesn't solve the problem 100%.
6. And why did they have to use exceptions for any kind of error mechanism? What's wrong with returning true/false and maybe add another way of retrieving details of error at my own peril? All these exceptions drove me nuts! Sometimes I don't want to be concerned if something very insignicant fails! Maybe I just check for a final result and that's good enough. But not in .NET - you can't leave anything unchecked! You have to add ugly try/catch block to every .NET framework call if you want to make sure that your app doesn't pop-up a very confusing message box to your end user.
These are just a few issues that come to my memory. I still recall that experience as big and very long nightmare. I like MFC and I'm still sticking to it, until an app written in it just won't run on some new version of Windows...
|
|
|
|
|
Hi Damir.
Damir Valiulin wrote: Sorry to bring up this 6 month old post
I don't mind discussing a 6 month old post, mainly because I can't say I really came to a definitive conclusion, and I feel the question remains to be answered.
Damir Valiulin wrote: I was working on certain ...Prop application...My task was to "fix it up" and I had two month (with lots of overtime) to do it.
I'd have to say I'm one of the few people who can really appreciate that...and it must have sucked. I hope you at least got a good bonus for your suffering 
Damir Valiulin wrote: I ended up almost rewriting the whole thing.
That seems to be a recurring theme. Unfortunately (and this seems to be common to almost all programmers) once someone sees an application that has 80% of the required features, it's very hard to convince them that the project should be started from scratch because the code is a steaming pile of .... 
If you want to build commercial-quality software that will last for many versions/years, it simply cannot be built from a foundation that was written by a student. Period.
1) Yeah, absolute pixels are right out of the 1980's !?! XAML should fix all of that - assuming you don"t have to ship anything before 2009 
5) I can't say I'm totally up on the subject, but I don't see how decent code protection (e.g. hardlocking) could ever be done in a byte-code system like .NET. From what I've seen, even obfuscated code is fairly readable when "disassembled". I don't think Microsoft is overly concerned about this, so I'm not sure if it will be solved any time soon.
6) I absolutely and totally agree with you on exceptions. They look great on a computer science chalkboard, but aside from file I/O, I would say exceptions are highly overrated for writing practical code. I think the main reason they're so popular these days is that it's great for framework authors (they just say "the caller will deal with it" and they're done), while sticking people like us with the hassle of catching all of their problems.
And (finally), for the topic at hand...
I considered C#/Winforms/etc quite thoroughly (I bought and read through a good number of books, and tried tons of sample code) and my opinion is:
i) I found C# very elegant compared to C++ (e.g. properties, events), with
the exception of not having destructors (which seemed like stepping back to the middle ages).
ii) I thought Managed C++ was too ugly (apparently MS agreed), and I would have to
say that while I think it's going to be popular for legacy code, I've yet to be convinced C++/CLI has a future for writing "new" code (i.e. how many people will use it over C# ???) Any language needs a lot of people picking it up, or it will die off quickly. So I don't think it's a good choice for that reason.
iii) I found every commercial Winforms GUI library that I could get my hands on to be surprisingly bad (compared to MFC/C++ components). They were either really sluggish or buggy. I don't want a window to flicker and be sluggish as I stretch it. It's 2006 and I have a 2+Ghz computer - is that really too much to ask?
iv) Microsoft is clearly moving towards Avalon / XAML. Winforms is already a "legacy" technology, so I don't think it's a good choice for that reason.
v) I asked the same question on "Joel on Software":
http://discuss.joelonsoftware.com/default.asp?design.4.230024.19
and most of the replies were quite negative about .NET / WinForms. It's good to get
a different perspective sometimes, since CodeProject/MSDN sometimes make you think
Microsoft is the only option.
vi) Winforms has been out long enough that it would make me nervous to choose it
for a desktop app, when there are so few applications that actually do this.
vii) If you haven't looked at it much, QT is very elegant. It's sort of a "modern" C++ framework that runs natively on Mac/Windows/Linux.
In the end, I think MFC is probably a good choice for another 4+ years. Technology changes too fast to predict more definitively than that. After that, my guess is the compiled-language programming world moves more towards a C# vs. Java split with XAML being used for "new" desktop apps on Windows (i.e. perhaps port MFC/C++ apps to XAML/C#). I also wouldn't completely rule out Linux-on-the-desktop or moving almost everything to being web based (ASP.NET / AJAX).
Because of all the uncertainty, the one thing I have done for my code is be religious about separating GUI and non-GUI code, to minimize the pain of porting over to something else, because you just never know...
Warren
|
|
|
|
|
Hey everyone, I hope this isn't too off-topic. I'm very keen to develop software for the Xbox 360, and ideally I'd want to do it in C#. At the moment neither of those things are possible though.
From what I've read, Microsoft is planning to open up development of the console, but I'm not sure by how much. I haven't read anything about them porting .NET to the Xbox 360 at all.
So my plan is to find out how many people share my interest, and to try and get a petition going to get some support for the idea.
Here is my text for the petition at the moment... if people could tell me what they think, what I should change, etc, I'd be really greatful. Once I've got enough feedback, I'll stick it up on PetitionOnline.com and try and get a good number of signatures.
Once again, sorry if it's off topic... this seemed like the best place to find interested people.
----------------
Xbox 360 Development with the .NET Framework Petition
"At this time, access to development tools for the Xbox 360 video game console is limited to developers working on approved titles for licensed publishers. This will change over time..." [1]
This petition is to encourage Microsoft to use the Xbox 360 console to promote .NET development, and in turn encourage developers (both professionals and hobbyists) to create games and applications that would run on the Xbox 360 under the .NET CLR.
This would allow any developer to exploit the power of the Xbox 360 and its convenient location in the living room without being hindered by requirements such as backing from a publisher or distribution costs.
Using the .NET framework gives a secure and isolated sandbox for applications to run in, which can be used to safeguard the Xbox 360 and the owner's data against malicious or buggy code.
An example of how this could be achieved is as follows:
The Xbox 360 Dashboard could have an "Xbox 360 Addons" area. This area could integrate with a site such as GotDotNet.com to allow Xbox 360 users to browse, download, rate and potentially buy .NET applications that have been written specifically for the Xbox 360.
The user could run these applications in the knowledge that the .NET sandbox provided by the Xbox 360 would protect their console from malicious code, and return them safely to the Dashboard should the application crash. Should an application hang (e.g. in an infinite loop) a special button (for example the Start button) could bring up a menu to terminate the application and return to the Dashboard.
For extra security, permission from the user would be required to enable an application to access features such as the hard disk (especially write access), the network (and therefore the internet), and extra accessories such as webcams.
Applications would have access to a managed DirectX interface to enable them to make full use of the console's hardware.
None of these features would be required to exist from the launch of the Xbox 360. Instead they could be added as part of a routine update to the Dashboard though Xbox Live.
Finally, none of this would be likely up upset Microsoft's revenue stream from games sales. Any large development project would still require the marketing, support, ease of use, and all the other benefits that comes with distributing a game through traditional channels.
In addition, Microsoft could implement some kind of payment scheme for downloaded Xbox 360 .NET applications through which they could get additional revenue.
This petition has been signed both by those who would like the opportunity to develop for the Xbox 360 using the .NET framework, and by those who would like the additional range of applications and games that could potentially be made available in the comfort of their living room.
[1] http://www.xbox.com/en-US/dev/developingforxbox360.htm
|
|
|
|
|
An interesting idea, but I don't think you'll get very far with it. The problem is the Microsoft (and Sony for that matter) sell consoles at a loss and make up the money by licensing games. If people could write and sell their own stuff for the xbox without giving Microsoft their cut then Microsoft would lose money.
From what I've heard Sony's latest PSP firmware upgrade did, amongst other things, lock out a lot of hacks that people had been using to write their own PSP apps. Sony doesn't get a cut from homebrewed apps so they don't want them on the PSP. Microsoft will no doubt take the same stance.
|
|
|
|
|
I'm completely with you 100%. I've been waiting to hear if they were going to do something in .NET so I could pursue a career in game dev. Where do I sign up?
|
|
|
|
|
Interesting but I'm not sure it will fly. Is there even a .Net Framework for the XP Media Center? (I honesty don't know either way) Does XBox360 even have the concept of "user" let alone principals?
Ultimately, I suspect the don't want to "open" any part of the XBox 360 due to lowering the bar for the evil specter of "piracy". If any Joe Programmer can write a C# program that can create a secure channel from the hard drive to the audio/video codec then what is the point of DMR or other security features they try to design into these things? Sure that would be great for us but rotten for MS.
So I guess I need to see exactly how they are going to open the platform up. If it is anything more pesky then what needs to be done for developing for PocketPC then forget it. If the API available to hobbiests is only a small subset where you can only create "toys" then forget it. Then the ubiquitous "someone" needs to implement a .Net Framework that is hopefully on par of the Compact version if not better *plus* documentation. All of this is some resource coming from somewhere...
In short, it would be nice but I don't know if it is even in MS's best interest let alone a good idea. Lower level programming on highly specialized hardware platforms is...how to put it...not as "fun" as a general computing platform.  I can't begin to think of what I would put on an XBox 360 since it is not a standard computing platform...
|
|
|
|
|
|
All the documentation and code examples I have seen for the WaitAny function states that this is a static function residing in the WaitHandle class. When I try to utilize this in my C# code I get the error message "System.Threading.WaitHandle does not contain a definition for WaitAny". (I am using ManualResetEvent and Threads within my application without any problems).
|
|
|
|
|
public static int WaitAny(WaitHandle[] waitHandles);
public static int WaitAny(WaitHandle[] waitHandles, int millisecondsTimeout, bool exitContext);
public static int WaitAny(WaitHandle[] waitHandles, TimeSpan timeout, bool exitContext);
xacc-ide 0.0.99-preview2 (now with integrated debugger)
|
|
|
|
|
I have this function:
[WebMethod]<br />
public string SetUserInfo(string AuthID, DataSet dg2)<br />
{<br />
if (AuthID=="********")<br />
{<br />
Oconn.Open();<br />
da.Update(dg2);<br />
Oconn.Close();<br />
return "it seems to have worked.";<br />
}<br />
else<br />
{<br />
return "Your Authentication Failed";<br />
}<br />
<br />
}<br />
and this is my da (dataAdapter) var:
public SqlDataAdapter da = new<br />
SqlDataAdapter();
but it keeps coming back with an error: "Update unable to find
TableMapping['Table'] or DataTable 'Table'"
http://digg.com
|
|
|
|
|
You should supply a DataTable named as Table in WebService function inputs(DataSet dg2)
|
|
|
|
|
public string SetUserInfo(string AuthID, DataSet dg2)
{
if (AuthID=="********")
{
Oconn.Open();
string connection = "server = localhost;database=urdatabase;uid=urid;pwd=urpswd";
string updatedata = "update urtable set AuthID = " + " '" + this.textbox1.text + "where AuthID = "********";
SqlConenction conn = new SqlConnection(connection );
SqlCommad cmdupdate = new SqlCommad(updatedata ,conn);
da.Fill(udataset,"urtable");
Oconn.Close();
}
else
{
return "Your Authentication Failed";
}
}
Maybe this helps u
Regards;
|
|
|
|
|
Hi everybody.
I load an assembly into another AppDomain, not a default one. As there is no way to unload the assembly, I need to unload the domain. This is where the app hangs.
The problem is this assembly has references to one dll, currently not performing any work.
I tried this:
1. Setting the assembly to null,
2. Implementing a ClassFactory and returning an interface of the object, then removing it,
3. Making assembly to implement the IDisposable interface.
None of this works. All examples on the Net just shows how to create AppDomains, load assemblies and then unload the AppDomain. None of those show what happens if the assembly has referenced assemblies.
Thank you for your help.
Sarajevo, Bosnia
|
|
|
|
|
I believe you also must unload the referenced assemblies. Is there a reason you cannot do this?
Picture a huge catholic cathedral. In it there's many people, including a gregorian monk choir. You know, those who sing beautifully. Then they start singing, in latin, as they always do: "Ad hominem..."
-Jörgen Sigvardsson
|
|
|
|
|
There is no way to unload the assembly at all. You can do this under Framework 2.0 but not under 1.1.
The only way is to unload the AppDomain, and it is clearly said that way at the Microsoft site.
The main assembly does not "realize" the AppDomain it is in is getting unloaded, so that it can do a clean up or something.
Also important to note is that no unmanaged code is accessed anywhere, so this is not the reason.
Thanks.
Sarajevo, Bosnia
|
|
|
|
|
Right, I was just saying that you could load the referenced assembly in the same appdomain and then upload that appdomain.
Picture a huge catholic cathedral. In it there's many people, including a gregorian monk choir. You know, those who sing beautifully. Then they start singing, in latin, as they always do: "Ad hominem..."
-Jörgen Sigvardsson
|
|
|
|
|
|
Okay, he probably meant AppDomain.Unload, but this is not working.
I will try today to impement a WaitHandle to set a ManualResetEvent so that the assembly stop processing if the service singals that it should stop, so hopefully the unload will work.
The funny thing is that this area is much improvedin Framework 2.0, you can do anything with unloading single assemblies from the AppDomain.
Thanks.
Sarajevo, Bosnia
|
|
|
|
|
I've tried loading assemblies that in turn refer to other assemblies in an AppDomain and it worked.
mirano wrote: This is where the app hangs.
Have you implemented any finalizers in your code? It's very much possible that one of the finalizers hung and that resulted in the hang?
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
