|
Cheese_kid wrote:
1)what is the command that we know whether the password is key in right or wrong??
Compare it to a stored password in a database?
Cheese_kid wrote:
2)what methods can we extract data from database??
You might want to start with the basics, try these[^] sites and articles.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Is this a known bug or something? I'm working on my code, I hit "run", it starts to compile, and I get an error. No biggie, I thought I may have one. It asks if I want to continue. I click "no" and I get dumped back to the standard visual studio layout.
Only problem, that friendly little task list won't come up. I hit the keyboard short cut, I try from the view menu, I try clicking on the little tab on the bottom of the screen - nothing.
It won't show up. Only happens when I work on my laptop, never have this problem on my desktop.
Ideas!?!?!
The ends can never justify the means. It is the means that determine the ends.
|
|
|
|
|
|
I don't think it's small. I mean... I see the tab that should expand it, but when I mouse over, nothing happens. Actually, a small percentage of the time i get a grey field to expand to the size the task list SHOULD be, but there's nothing in it.
And I'm using 2003, by the way.
Oh well... if I restart VS I can get it back, but it disappears after the first use now...
The ends can never justify the means. It is the means that determine the ends.
|
|
|
|
|
yeah hapened to me once. try minimizing properties and solution xplorer til u find ur task list. chances are its behind one of the other sub windows.
Aim small, miss small...
|
|
|
|
|
I've seen this with the task list and some search results when I have auto hide on the container. I hover over the name and it refuses to expand until I expand one of the other items and click the push pin icon.
I can imagine the sinking feeling one would have after ordering my book,
only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
|
|
|
|
|
:(Recently I want to design a report forms that base on excel2003.But the primary function in Excel 2003 can not satisfies the business needs.So I have many funcations to get data from SQL Server in c# .I want to transform these function into Excel 2003 custom function.
Can you tell me how to do it?
Thanks!
|
|
|
|
|
You would have to go one of three routes.
1) Write Excel macros in VBA, using ADO to get the data out of the database and then populate the spreadsheet with the values you get back.
2) Use Visual Studio Tools for Office to write your "macro" code in C# and use ADO.NET to get your data out of the DB. This assumes that you can afford VSTO or that you have an MSDN subscription.
3) Use the Office Primary Interop Assemblies to make calls out to Excel. This is a lot more cumbersome than using VSTO, but it's free (assuming you have Office installed).
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
|
|
|
|
|
Hi ,
I am a little bit confused.
I have a tree view , currency manager and a datagrid
Currency manager controls item details ,
TreeView is bounded by the following structure
ItemRootTypes -> ItemTypes->Items
DataGrid has the same source as CurrencyManager.
I could navigate through records by both side, syncronizing each other, selecting the correct node/CM_Pozition with the given itemID
(TreeView -> CurrencyManager & CurrencyManager -> TreeView)
I could find the appropriate record in the TreeView and select the node by SelectedNode property of TreeView.So far everything works fine.
But if the currency manager's index changed by DataGrid ,
TreeView could find the appropriate node , but cannot select the node.(highlight)
(I check it by changing the node's text )
Btw , databinding still works , the only problem is TreeView cannot select the node.
Anybody has dealed with the same issue ?
Thanks in Advance
Teknomultimedia
|
|
|
|
|
|
Hello partners..
I've been searching the net for an RTSP C# source code to start building it myself.. but i seem to have no luck finding one and i am stuck as i have no clue how to begin!! so i would apriciate some help and if u can send me a source code on my email :
waleed.marji@google.com
thank u guys
|
|
|
|
|
There is an application that gets ran full screen, the owner doesnt want it to be minimized or closed without a password.
I know one can create a hook into this application and listen for events, but what event would be fired when a minimized gets fired? Also, given I can see this event, how can I intercept this event and handle it instead of the application?
I tried suggesting writing an application for the client that would do exactly what this app does, but to no avail.
Any help would be appreciated.
Steve Welborn
Software Architect
|
|
|
|
|
You have to create a system wide hook (WH_GETMESSAGE[^]) to see the messages being sent to the applications message pump.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
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...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
