|
Texas-Tundra wrote: I will try and not bother the forum with questions as much as possible.
We are fine with questions - provided you show us you have tried - just try to remember that we only get what you type! 
Use code blocks to mark code and it becomes a lot more readable - edit your original question and you'll see what I did; there is a "code" button above the text box which will do it for you.
And show us relevant fragments of you code, not the whole thing - it makes it a lot more likely that someone will read it and try to help.
Hopefully, you are on a course or following a book to learn this stuff rather than random guesses or *shudder* YouTube "tutorials"?
"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!
|
|
|
|
|
Well actually I am using the school of Google and ChatGTP. I did way back in 2004 take a semester of .lisp and .vba. But they really do not translate well into this. But I am probably going to look into some online learning courses. Being in Houston there is a lot of training schools and online classes.
|
|
|
|
|
Quote: I am using the school of Google and ChatGTP
Don't do it like that, please.
Trouble is that unless you know something exists, you can't look for it - a course or book presents everything in a structured manner so it's easier to understand, and provides exercises to check your comprehension. It also helps to "cement" the learning - we learn by doing, not by looking - you can watch as much of the Tour de France as you like, it won't teach you to ride a bicycle! 
"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'm putting this in C# since it's an issue with initializing NET...
I have a WinForm DLL that is written to be DPI-aware. It is called from both C# and C-based executables. There is an intermediate mixed-mode C / CLR / C# DLL between the executable and the Winform DLL that calls from C to Managed C++ to C# to launch the WinForm DLL. Both the C and the C# exe are also DPI-aware (as appropriate for their language) and both display correctly.
Here's the logic flow.
C or C# exe:
- calls into the intermediate's cdecl entry point using the usual LoadLibrary / GetProcAddress mechanism
intermediate mixed-mode DLL:
- C entry point makes a call to an internal CLR function
- CLR function marshals the parameters, does a gcnew on a C# class and calls its single member function
- C# member function:
Assembly targetAssembly = Assembly.Load (File.ReadAllBytes ("path to winform dll");
Type startType = targetAssembly.GetType ("startupNameSpace.startupClass", true);
object startLib = startType.InvokeMember ("", BindingFlags.CreateInstance, null, null, new object[0]);
startType.InvokeMember ("startupMethod", BindingFlags.InvokeMethod, null, startLib, new object[] { marshalled parameters } );
WinformDll:
- startupNamespace.startupClass is NOT a form, just a plain C# class
- startupMethod creates a parameterized thread, sets the apartment state to STA and starts the thread passing the marshalled parameters
- the thread instantiates the first WinForm class with the parameters and calls ShowDialog
So, here's the problem.
When run from a C# exe, the DPI logic works correctly. I have a C#exename.exe.config file in the same directory with the exe that contains a "startup" section with my framework version number and a "System.Windows.Forms.ApplicationConfigurationSection" section containg the DpiAwareness key with a value of PerMonitorV2.
When run from a C exe, the WinForm display is incorrect in the exact places where I have my DPI-handling logic. It's obvious from the display that the property DeviceDpi is incorrect for every form. The research I've done leads me to believe that the .NET environment created to run my winform assembly is missing the dpi awareness flag that is set in the config for the C# exe. I've tried adding a config file with all the different name permuations using the C exe name, the intermediate dll name, the Winform dll name, "exe" and "dll". Nothing is picked up by the NET subsystem that is automatically loaded for me.
So the question is -- how do I force the NET subsystem to see a config that sets the DPI state?
Judy
Also, I have tried the solution to fix an incorrect DeviceDpi when an exe is first run on a secondary monitor (in the form's OnHandleCreated, call GetDpiForWindow, scale it, resize the form, and send a WM_DPICHANGED with that retrieved dpi). Putting this in the first form displayed does not fix the incorrect display.
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
.NET Framework or .NET Core?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Framework 4.7.2
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
I'm writing a program that allows users to send commands to various serial devices. Most of the commands are "Button" orientated. By that I mean they press a button and everything is done for them; however I have a textbox that allows them to type in manual commands should there be something I don't have a button for that they really want to happen. I'm thinking about logging what commands they are typing in order to improve my program so that I can add other buttons that will help make life easier all. I'm wondering if there's a way to do that possibly on Github so that I can retrieve basically over web. Or if there's a better way to do it? I'm currently working in Csharp/WPF. I'm also thinking about logging some try/catch handler errors, so that I can analyze software bugs too, but I'm not too bothered about that right now.
|
|
|
|
|
First of course be aware of your user base. You are collecting information about them by doing that and there might be customer relation problems with that. And legal ones as well.
Other than that all your are doing is collecting data remotely from an application. There are many ways to do that.
geomeo123 wrote: if there's a way to do that possibly on Github
As in that there is a library for that? Or that you want the data stored on Github? For the first I am certain there is. As for the second that wouldn't be my choice.
geomeo123 wrote: thinking about logging some try/catch handler errors
You should create a code API that logs the following
- location. File/method.
- Text that describes what it is
- Additional information. This would be where you put exceptions, including stack traces.
Then you call that where ever you want.
There are specific libraries that provide 'logging'. In C# I have used log4net and Nlog.
That provides the API that I mentioned ready to go. It does not however provide the 'destination'. I know you can find addins to log to databases. I suspect others.
Another problem you will have is that since your application is remoting pushing data then someone might do something malicious to abuse your system. Basically you need to figure they will attempt this. So at a minimum you need to provide credentials. Although that probably is not enough. You might want to throttle as well so if they hack your app they can't just start blasting away.
There are services that provide APIs that collect data also.
|
|
|
|
|
jschell wrote: There are many ways to do that
If I may, but you didn't mention what any of them are. I too have been asking myself this question and I'm very interested to know what other people think.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I don't think he knows. Think we might have to go to a university and earn a degree to figure it out.
|
|
|
|
|
Richard Andrew x64 wrote: but you didn't mention what any of them are.
Some of them:
To a SQL Database
To a no-SQL Database
To an event hub
To flat files
To a service that collects metrics.
To a custom server API.
To Syslog
To Azure OpenAPI
To AWS OpenSearch
|
|
|
|
|
|
Ah, Log4Net. From the glory days of .NET, as I moved from (work) place to place everyone used it. Seems to have lost favour in the Core world, and been replaced by something more standardised and flexible, but not as to-the-point 
Two line logging, whoever thought that was a good idea?
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: and been replaced by something more standardised and flexible,
What exactly?
|
|
|
|
|
I use Winform and I use Entity Framework to communicate with the database and I use the MSSQL database and when I want to connect the SQL database to the Visual Studio program, the table Those that exist in my database are not present as classes in the Visual Studio program
|
|
|
|
|
If you're talking about using the Data Sources tab in Visual Studio to connect to the database, and you're using Entity Framework, you're doing it wrong. The Visual Studio designers will not create classes for Entity Framework. You have to write the classes yourself.
|
|
|
|
|
If I connect the data base to Visual Studio and create my own classes, will Visual Studio connect my classes to the tables in the data base?
|
|
|
|
|
It appears you have no idea what Entity Framework is or how it works, correct?
Visual Studio isn't going to do anything for you when using Entity Framework, nor should you rely on it. Using the designers in Visual Studio hides a bunch of details from you that makes learning how to interact with databases more difficult to learn. You don't need anything from Visual Studio to work with databases.
|
|
|
|
|
Downloads: Generic Database Access[^]
This a HUGE Codeproject article which, from the looks of things (quick scroll through the .zip content), is likely to give out many C# programming secrets wrt SQL Server (even) with no further sacrifice of time searching on your part.
Generic Database Access[^]
|
|
|
|
|
I have a strange issue I am experiencing with a web app. Typically, the user right clicks on the web page and click Print. He views the document in preview and then decides how to print it.
On Chrome, everything works fine
On Microsoft Edge, It only works if you right click the web page at the top of the page. If you scroll down to the bottom of the page before you right click and select print, the printed document is not formatted properly. The print preview is also not formatted properly. See screen shots below:
On Chrome - (User right click from bottom of page)
You can see the title of the app, title of the report, report run date etc
Report Issue - Chrome.PNG - Google Drive[^]
On MS Edge - (User right click from bottom of page)
The preview starts at some random data as shown below. Title of the app, title of report etc are not shown in the preview and printed version.
Report Issue - MS Edge.PNG - Google Drive[^]
As you can see from the above screen shots, Chrome is displayed properly. MS Edge only displays like that if I right click on the web page from the top of the page without scrolling down
Below is my code sample:
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Physician Activity Report</title>
<link rel="stylesheet" href="~/lib/bootstrap/dist/css/bootstrap.min.css" />
<link href="~/lib/font-awesome/css/all.css" rel="stylesheet" />
<link href="~/css/mycss.css" rel="stylesheet" media="print" />
</head>
Below is the content of mycss.css
@media print {
.col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6,
.col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12 {
float: left;
}
.col-md-12 {
width: 100%;
}
.col-md-11 {
width: 91.66666666666666%;
}
.col-md-10 {
width: 83.33333333333334%;
}
.col-md-9 {
width: 75%;
}
.col-md-8 {
width: 66.66666666666666%;
}
.col-md-7 {
width: 58.333333333333336%;
}
.col-md-6 {
width: 50%;
}
.col-md-5 {
width: 41.66666666666667%;
}
.col-md-4 {
width: 33.33333333333333%;
}
.col-md-3 {
width: 25%;
}
.col-md-2 {
width: 16.666666666666664%;
}
.col-md-1 {
width: 8.333333333333332%;
}
}
h5 {
color: darkblue;
}
What can I do to get this to work properly on MS Edge ? Is it a CSS issue ?
|
|
|
|
|
No idea what the answer is but I did upvote the question because someone down voted it and without explanation. Seems like a reasonable question to me.
Perhaps they wanted you to post in a different forum but didn't feel like explaining that.
|
|
|
|
|
Yeah. It is a strange issue that our users recently brought up. Most users use MS Edge. I don't know what angle to analyze from. It is a .NET Core web app.
|
|
|
|
|
I use Edge as a secondary browser when Firefox fails to display a dark background with light foreground because it (Edge) and it's settings remain at default. Nothing there in a contextual right-click and print (apparently CTrl+P also) fails when the target format is .PDF; so I suggest ... printing from the saved .pdf document instead of printing to .png.
|
|
|
|
|
Hi @RedDK, thanks for your input. Yeah CTrl+P also fails. Like I said in the question even the generated PDF is not formatted properly for MS Edge. Why is it that it works if I right click and click print from the top of the web page but as soon as I scroll down and do the same action it doesn't work in MS Edge ? What can I do to fix it ? What code do I need to add? Why don't I experience same issue in Chrome?
|
|
|
|
|
Perhaps your reticense to post actual code instead of showing images through links is what's keeping me from seeing what could possibly be wrong here. I can right-click and Print this as-is ... with no difficulties.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
