Many thanks to everyone's input, I will try a "clean" build as recommended and hopefully post results back up here for future reference.

Pound to fit, paint to match

Thanks I will give that a try. To distill things down further: is it possible that code written 10+ years ago will have problems building under .NET 8.0 and will require re-writing the code to build successfully? Or is the one way upgrade system good at catching potential problems and resolving the changes to the code?

Pound to fit, paint to match

Ok, my previous post was a great example of how not to describe what I am looking for, mea culpa. To give a more concrete example: Fast Colored Textbox is available here on CodeProject, as well as Github. It was posted in 2014, and has a target framework of .NET Framework 3.5. With VS 2022 17.8.2 (as of yesterday), the default target framework is .NET 8.0. To clarify: evidently, even though I am sure that Microsoft works very hard to keep backward compatibility, the process of upgrading the program to .NET 8.0 is not trouble free. When you open the original files and start building, VS 2022 starts with a "One-way upgrade" conversion, and it says it successfully migrated. When you build the project, you get a dozen errors about "invalid RESX file". Now I have not dug into the errors per se, but the naïve question is what is the root cause of these errors? Is it: a) Just a matter of ensuring all supporting files are in a location that the compiler can work with, or b) You can't count on the "one way upgrade" to do everything for you, or c) There is code from 2008 - 2014 .NET 3.5 that is not compatible with .NET 8.0, or d) all of the above, or something else Of the three, it is item C that I am mainly concerned with. Hope this makes more sense than the original post. Thanks to all for input received to date. BTW: I mentioned that I work mainly in VB.NET as a nice way of saying I do not do programming for a living.

Pound to fit, paint to match

Lets start off with a little honesty - I am unsure of exactly what I am asking, but I am sure that someone can help. So I currently have Visual Studio 17.8 installed. I predominantly work in VB.NET. I have some older code downloaded from Github, that works just fine (as binary) when it was put together say 10 or more years ago. The crux of the problem is that you (and by you, I mean me) cannot in some cases simply drop it into VS 17.8 without several errors. Therefore, the naïve question is - can anyone point to a good source of information that would guide me on how to "upgrade" older code to eliminate errors in compiling with the current versions of VS and .NET? THanks.

Pound to fit, paint to match

I would encourage all with sleep problems to get a sleep study done. My wife nagged me until I did about 5 years ago, and wound up with a CPAP (a BPAP technically). Greatly improved my sleeping habits to the point I almost cannot even take a simple nap without it, but well worth the 6 - 8 hours of uninterrupted sleep w/o sleep medicine or supplements.

Pound to fit, paint to match

Generating a small printing program. I have Brother color laser printer that can duplex print. However, when I get the CanDuplex value, it returns False:

pd.PrinterSettings.CanDuplex

The interesting thing is that checking for color capability works just fine:

pd.PrinterSettings.SupportsColor

Accessing the printer via conventional MS Office applications (as well as other applications like Acrobat) has no problem identifying that the printer can print in duplex. Thoughts?

Pound to fit, paint to match

Some more progress: 1) the darn dollar sign $ From your response: "The first WRITE loop is the one indenting the line properly, which apparently is not valid in F77, as both our F77 compilers failed to do proper indentation. Maybe the format string could be updated to F77 standard; it just specifies two space characters to be output." So my interpretation is that WRITE(IF, '(''$ '')') simply writes two spaces, and can be replaced by write(*,*)' ' where there are two spaces between the single quotes. That makes a lot of sense. The $ sign has been used in various compilers to indicate a macro, or as a suppression of line return, so that helps a lot. It might be some compiler specific feature. 2) The compiler is not happy with the first do loop in SUBROUTINE: DO FOR RETURN = EXTERNAL, EXTERNAL - IF IMPLICIT(RETURN) = LOGICAL(RETURN) + LOGICAL(RETURN - IF) END DO The complier will not throw an error or warning (either when compiling or running), but as I see it, the first time through EXTERNAL = 0 and IF = 1, so you are doing a negative increment DO FOR RETURN = 0, -1 when I test a program with a do loop like above, there are no errors or warnings from the compiler, and the program runs, but it apparently just skips over the do loop and its contents. For example, this code write(*,*)'before do loop' do RETURN = 0, -1 write(*,*)'inside do loop' end do write(*,*)'after do loop' produces the following output: before do loop after do loop 3) The declaration of variables in the main program have IMPLICIT and LOGICAL as scalars, and then are redeclared as arrays in SUBROUTINE; there is no definition of the size of the array (should be 13). Likewise, EXTERNAL is declared as an real in the main program, and redeclared as an integer in SUBROUTINE. 4) last but not least, F66 and F77 limited variables, subroutines, functions, program names to 6 characters; how did your compiler accept the ones that are 7 or more characters long? Thanks again!

Pound to fit, paint to match

Thanks for your response. The Simply Fortran 3 complier did not complain about the "FOR" between DO and variable, I had never seen that syntax, and just wanted to make sure this was not a misunderstanding on my part. My recollection is that prior to, and including F77, there were dozens of "dialects" of Fortran because folks just wanted to add features in their compilers that were not in the standard, resulting in difficulties in porting the program between various machines and compilers. I also have the Intel Fortran compiler which is supposed to be compliant with F66, and will try to run it through that when I have the time. All of my work is being done as a console program under Windows 10, using the Simply Fortran 3 program. I am in the process of reverse engineering the code (manually refactoring to a certain degree), and will be happy to share the revised code when done. I do have a few questions for you, my apologies for asking; they involve subroutine SUBROUTINE: 1) The first line in the subroutine (re)declares the variables. I am a little rusty on subs, but it seems that this would reset them all back to zero? (BTW - I had to explicitly declare the variables in the main program as zero; the Simply Fortran compiler is based upon the GNU fortran compiler, and if you don't initialize the variables, it puts a non-zero value in each uninitialized variable, which messes up your program) 2) The compiler does not like it when you have variables declared as integers in the main program, and then re-declare them as one dimensional arrays within the sub (eg - IMPLICIT and LOGICAL) 3) I am reworking the program as a simple console program running under Windows 10. I don't seem to recognize the following syntax: WRITE(variable, 'string') what are these WRITE statements actually doing with the variable and then the string? Last but not least, it appears that the subroutine FUNCTION does absolutely nothing. I did a listing of the variables before and after calling FUNCTION, and there were no changes. Was this by design? Overall, this is an excellent program to torture new users of Fortran to drive home the point that even though you could use keywords as variables, you really should not. I was also a TA as a mechanical engineer back in the '70s, and would also do things like this to my students.

Pound to fit, paint to match

A couple more things 1) I think only IV/66 always went though a do loop, and 77 and beyond does not 2) I asked about the space between FOR and IF because there is not DO FOR ..... loop. I ran your code through Simply Fotran compiler set for legacy code and it thinks "FOR IF" (or "FORIF") is a variable, which does fit the syntax DO FORIF = variable, variable.

Pound to fit, paint to match

1. is it possible that you added a space after DO FOR... that should not be there? 2) no DATA statements or other initialization of the varables?

Pound to fit, paint to match

Well this method is more practical for digitizing video tapes (ironically onto DVDs). If I want a backup of a commercially available DVD, I would buy a used one on eBay for usually less than $5.

Pound to fit, paint to match

I got into it a number of years ago to digitize my video tapes of my daughter from 30+ years ago. My memory was that pure software conversion solutions were always 1 or more steps behind the copy protection schemes. Conversion using the cheap USB converters (< $50) was only acceptable for standard definition video due to throughput limitations. Evidently a HDMI signal splitter strips out any copy protection signals, and a 4K BlackMagic PCI video capture card does the heavy lifting on digitizing the input signal. It outputs an uncompressed videos and audio file, which must be further processed into the final file format such as MP4. And time consuming, as it takes 2 hours to digitize a 2 hour video, and then more time to convert the raw video and audio file. All of this is really too much for just copying a couple DVDs (or video tapes). But if you have lots of videos to digitize and quality is a consideration, this may be a viable option.

Pound to fit, paint to match

If you want to try the hardware route, you can take the HDMI output of the DVD player through a HDMI cable splitter to remove the copy protection signal and then feed into a good (not cheap but under $100) video capture card such as the one from BlackMagic. The resulting file will be about 1gig per hour of video, and you will have to convert the output to the final desired format. But the final file will be of quality equal to the original.

Pound to fit, paint to match

So I started a VB project with a main form, and added a menu strip to the form. As I continued, I added a tab control with six tab pages. I then realized (duh) the potential folly of using a central menu strip with multiple tab pages. So seeking your input/wisdom; do I: 1) place a dedicated menu strip on each tab page: 2) keep a central menu strip at the top of the form AND dedicated menu strips on each tab page; 3) use a central menu strip for the form, and then programmatically enable/disable menu items based upon the active tab page; or 4) do something else (like using an UI alternative to tab pages)?

Pound to fit, paint to match

"Well, something's going on that isn't normal." and hence the title of the post. Going to the application tab and selecting Form1 as the startup object, compiling, and then changing the form name in Solution Explorer allowed compilation without an error. However, I will note that after changing the form name from Form1 to frmMain as above, in the application tab/startup object, it is still "Form1" and not "frmMain". And while the form name in Solution Explorer is "frmMain", when you click on the form and look at Properties, it is still "Form1" My Win10 pc and VS are both up to date. Now here is where it gets even more interesting. Once again start a new project, VB/windows form/desktop/,NET 6, let the solution come up with Form1. Go to Project, Add form, and add a new form. At this time you can call it "frmMain" when it is added. Then go to Solution Explorer, select Form1 and delete it. So at this point, Form1 is gone, and only frmMain remains. Go to application tab/startup and select frmMain as the startup object. Build the solution and then you get: Error BC30456 'Form1' is not a member of 'test6'. Now VS is throwing errors on a "form" that has been deleted from the solution. So I know there are work arounds, but the (somewhat rhetorical) question is: why doesn't VS automatically update all references in the solution when a form's name is changed/deleted?

Unfortunately, when I create a new project, let Form1 come up and then click on Form1.vb under Solution Explorer, click on Form1.vb, press F2, rename Form1 to frmMain, and then build, results in exactly the same build error.

Yes I did. Following the same steps, create a desktop VB windows form .NET 6 project, let the project come up with the standard Form1, then right click on Form1.vb in Solution Explorer, rename as frmMain.vb results in the same error message when you build it after the name change.

Using Visual Studio Community 2022 17.1.1 1) Select Visual Basic/desktop/windows form/.NET 6 project opens with Form1 as default no code, no changes, Build Solution, compiles with no errors 2) Select Visual Basic/desktop/windows form/.NET 6 project opens with Form1 as default using the Properties window, change the name of Form1 to frmMain, save all files no code, no other changes Build Solution = BC30451 'Form1' is not declared. It may be inaccessible due to its protection level So the question is, if I change the name of a form, do I need to do something else such that VS/VB will "update" everything to acknowledge Form1 has been renamed frmMain?

I do not code for a living, and infrequently use VB.net under Visual Studio. When starting a new project, the statup up form name is Form1 in vb.net (this is under VS 2022 community). If I leave the form name as Form1, then no problems when I build the project. But it seems (and this could be user error on my part), if I change the form name to something else like frmMain, then when I build the project, VS provides compiler errors such as: Error BC30420 'Sub Main' was not found in 'ModuleTest2.frmMain' or Warning BC40046 class 'frmMain' and partial class 'frmMain' conflict in namespace 'Moduletest', but are being merged because one of them is declared partial. So apparently I am doing something wrong but it seems to me that changing the first form name to something other than Form1 should not cause such a fuss. Input?

Want regex to match the following pattern in the first 5 positions (only) of a line of text: position 1............2..............3..............4..............5 s........s or d.....s or d.....s or d.....s or d where s = white space, n = digit The first position is always a white space, and the next 4 positions can be one or more digits. examples: s1234 ss123 sss12 ssss1 s1sss s12ss s123s I tried ^\s+\d+ In an online regex tester, this matches the digits perfectly in the first 5 positions and not any where else on the line. However in a C# program, it is matching not only what is in the first 5 positions of the line, but also any other combinations of s and d on the same line, such as good.......................bad............................bad match.....................match.......................match 12 text text text 53, text text text 123 suggestions? I thought ^\s{1,4}\d{1,4} would narrow things down to the first 5 positions of the line, but that does not work either.