|
Sorry for being late to the party. You do not, ever, use a MessageBox in a non-GUI app. In services we write to the EventLog, in console we write to the.. console.
Replace it with a Console.WriteLine. After that, we'll look further. But never, ever, use something that displays a UI on the console. If you think you need an OK-Cancel button, you wrong. You need to readline (Y/N) on the console.
Is this during an education?
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
You're looping and simply displaying the same information. Your "5" corresponds to the 5 items in your array.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I’m trying to get a better understanding of net framework. I used to think net is just a MFC replacement. GUI programming on Windows the easy way. Windows is basically GUI tied to device drivers. In my mind .NET doesn’t reach the driver level, it’s just shallow scripting
|
|
|
|
|
Yes, in the same way that a F1 car is just a Ford Fiesta replacement.
You can compare MFC to .NET, but .NET is a lot more than "just a windows framework" - MFC is just a structured C++ framework around the Win32 API. But it made Windows development so much easier than the entirely manual message handling that preceded it. And .NET makes development so much easier than MFC was*. It's also language agnostic in a way that MFC never could be, despite being a solid part of C# - to the point where C# can't actually do much if anything without .NET behind it to provide even basic string handling! The number of languages that you can use .NET is is pretty impressive - and any assembly written in one of them can be used in another as it it was written in the same language.
I used C for Windows, Then C++, then MFC/C++, and finally moved to C# with .NET and despite it's vast scale it's pretty much consistent: it something works for one control, there's a good chance the same properties will exist in another for example.
Would I go back to DLL Hell and MFC? Not a chance in Hades!
* You may have noticed that I didn't mention "Windows" with .NET - it also exists for Linux, Android, and iOS via Xamarin. Try that with MFC ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I feel like I’m traveling back in time. After seeing what Windows forms is all about it’s time to see what MFC can do. But this thread is about .net. I should probably look into what other things .net comes with, besides forms
modified 9-Nov-22 4:36am.
|
|
|
|
|
Shed loads.
I'd strongly suggest a book on the subject: they should present the whole of .NET so you don't miss something you could have used later if you had known about it!
Wrox do good ones, as do Addison Wesley and MS Press.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
You're welcome!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
.Net is a combination of many things. The GUI designers are more like VB 6 and VB prior to 6.
.Net does not have the equivalent of the Document/View architecture built into it as it is in MFC.
.Net does not support mixing languages using a linker as does unmanaged code does. Use of multiple languages by a .Net application requires that each language be a separate executable (DLL or the single exe file).
Much of .Net is based on Java.
The .Net intermediate language might be an evolution of the technology Microsoft had in the original Basic interpreter in DOS.
The designer and original developer of C++ explains that C++ does not support the kind of feature (such as the .Net intermediate language) that provides the portability that Java and .Net languages provide.
|
|
|
|
|
Sam Hobbs wrote: Much of .Net is based on Java.
How much are you saying is based on Java?
And what do you mean by "based on?"
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
There are some 124 name spaces in the framework / class library; maybe 20% are dedicated to GUI programming. UWP and WPF use DirectX; which is close enough to driver level.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: There are some 124 name spaces in the framework / class library
Try counting again - there are 2305 namespaces listed here[^]. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I just Googled for a number; it returned one big enough to use. I suspect there are "major" ones and "minor" ones. I'll even take your word for it without bothering to check.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Sam, Gerry thanks for feedback
|
|
|
|
|
I have a one-man-show small business with a complex, mature and utterly reliable .NET Framework 4.6.1 WPF app and associated libraries, etc. I'm always busy adding requested features and doing customizations for my customers. My question is - how important is it that I drop my income-generating activities and port all of this to the latest .NET 6 or whatever? I would value advice from those who have done this upgrade...
|
|
|
|
|
"If it ain't broke, don't fix it."
Start a new project with the latest version - no point in upgrading software if you aren't adding features, all you do is risk adding problems or inefficiencies because you aren't fully familiar with a new framework (however similar it may be).
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Having read the comments on your article about non binding MVVM I imagine your "upgrade" would be a bloody nightmare having gone down a non standard path (assuming you have maintained that style).
The greatest nightmare of a one man show - when do I HAVE to move to the latest version of my tool(s), all the while building technical debt. Think of the poor sods still on VB6!
I agree with OG - you need the income stream and stability, unless your clients are screaming for the latest version I would leave it. When (Ghu forbid) they demand you go to a browser based solution then you change!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
That "MVVM without binding" project was such a failure that the last time you flew in a commercial jet, the turbine blades might have been shaped by that software 
My clients (industrial machine builders) wouldn't know a Framework from a Core from a Standard unless I whacked 'em on the head with them.
|
|
|
|
|
I found it easy to move from WPF to UWP, and now prefer UWP because of the Windows Store though I think you can move WPF to the store now (easy customer distribution). I also think the UWP event model is more comprehensive. And there's local and roaming storage, etc. Nothing you would miss unless you went looking, and then you do.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I moved many thousands of lines from .Net Framework 4.x to 4.81 to finally move them to .Net 3 up to .Net 7.0 (including WPF programs). The main job is to redo the project in the new .Net format, compile and correct the few compilation errors you found. This answer gives a hint on the difficulty problem but don't address the importance of porting it to .Net Core.
Jacques Fournier
Consyst SQL Inc.
www.consyst-sql.com
|
|
|
|
|
Bruce Greene wrote: My question is - how important is it that I drop
You have two customer bases
1. Existing
2. New
For both types of customers do they buy new hardware? How often do they upgrade windows?
Leaving it as is runs the risk of, at some point, your software will fail in some odd way or not run at all because of updates to windows.
However updating also runs the risk that will not run on older versions either.
These days older apps also have an increased security risk. Or at least it is perceived that way. So it is possible at some point that something (like a virus checker) might flag the app for something. Which makes customers nervous.
You might also want to validate how exactly your build process works. If you are expecting to be able to download libraries (specific versions) any time you want at some point that might no longer be possible. You can address that keeping the libraries in your own source control and download nothing.
Besides the customers the primary way is to look for "end of life" for anything. Could be operating system, libraries, hardware etc.
For the version you specified above the date is April 26, 2022. It is unlikely anything will fail now. But you probably don't want to still be waiting 5 years from now.
Microsoft .NET Framework - Microsoft Lifecycle | Microsoft Learn[^]
If you have customers that do not upgrade then you will also need to plan on continuing supporting them. Note that this also means that you will need to have hardware and operating system that you can both test on and develop on. Keeping in mind however that even if it is good money maker at some point even they will find it difficult to keep running with the old equipment. Although some people are very ingenious at finding sources.
|
|
|
|
|
Using C# and Word 16.0.
var wordApp = new Microsoft.Office.Interop.Word.Application();
wordApp.Visible = false;
Document wordDoc1 = wordApp.Documents.Add();
Document wordDoc2 = wordApp.Documents.Open(@"c:\users\robertsf\desktop\doc2.docx");
When this code executes, wordDoc1 gets clobbered, everything returning COM Exception, and wordApp.Documents contains only one object, the opened document.
var wordApp = new Microsoft.Office.Interop.Word.Application();
wordApp.Visible = false;
Document wordDoc1 = wordApp.Documents.Add();
Document wordDoc1a = wordApp.Documents.Add();
Document wordDoc2 = wordApp.Documents.Open(@"c:\users\robertsf\desktop\doc2.docx");
When this code executes, wordDoc1 gets clobbered again, but wordDoc1a is fine, and wordApp.Documents contains two objects.
var wordApp = new Microsoft.Office.Interop.Word.Application();
wordApp.Visible = false;
Document wordDoc2 = wordApp.Documents.Open(@"c:\users\robertsf\desktop\doc2.docx");
Document wordDoc1a = wordApp.Documents.Add();
When this code executes, however, everything is fine. wordApp.Documentscontains two objects, and each object is accessible, as expected.
I'm trying to programmatically create a new document and copy the text of a variable number of documents into it. I suppose I could open all the source documents before creating the destination document. Or I could try to create two instances of Word.Application, one for the source documents and one for the destination document, and then see if I can copy between the two instances.
Here's the MS documation.
Add: Documents.Add(Object, Object, Object, Object) Method (Microsoft.Office.Interop.Word) | Microsoft Learn[^]
Open: Documents.Open Method (Microsoft.Office.Interop.Word) | Microsoft Learn[^]
I don't see anything about one operation overwriting the other. ¯\_(ツ)_/¯
|
|
|
|
|
I was going to delete this, but I'll leave it up in case someone else has the same problem. Here's the solution -- the call to Documents.Open has to have more arguments. The MS documentation says they're optional, but there are side-effects to not providing them.
var wordApp = new Microsoft.Office.Interop.Word.Application();
wordApp.Visible = false;
Document wordDoc1 = wordApp.Documents.Add();
Document wordDoc1a = wordApp.Documents.Add();
Document wordDoc2 = wordApp.Documents.Open(@"c:\users\robertsf\desktop\doc2.docx",
false, false, false, "", "", false, "", "", WdOpenFormat.wdOpenFormatAuto,
MsoEncoding.msoEncodingUTF8, false, false, none, none, none);Now it works as expected. I haven't experimented to see exactly which argument caused the issue.
|
|
|
|
|
This is my code.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class PlayerController : MonoBehaviour
{
public float JumpY = 10;
public float JumpZ = 1;
public float JumpX = 0;
// Start is called before the first frame update
void Start()
{
}
// Update is called once per frame
void Update()
{
if (KeyCode.Space = true)
{
transform.translate(0, 10, 1);
}
}
|
|
|
|
|
Just like the error says. You're missing a closing curly brace at the end of the code.
If you're not indenting your code properly, it's easy to lose track of the braces that should match up.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
