I have successfully installed MonoDevelop with the F# bindings (under Linux Arch).
If I try a simple HelloWorld with winforms, I get this strange behavior: the program compiles and builds successfully, but a moment after the window is loaded it just closes itself and the program returns with no error messages.
I checked the logs and it seems no error is thrown (except from the one discussed here: GLib-CRITICAL **: Source ID XXX was not found when attempting to remove it, which anyway seems unrelated).
The code for the program:
open System.Drawing
open System.Windows.Forms
[<EntryPoint>]
let main argv =
let form = new Form(TopMost = true, Text = "Hello World")
form.Show()
0 // return an integer exit code
If I try to run it through the interactive console, the window is sort of freezed: I can move it around, but I can't close it (have to shut down monodevelop in order to do so).
I also tried to compile it via terminal, using:
fsharpc Program.fs -pkg:dotnet.dll
mono Program.exe
but it behaves the same way as if I was running through MonoDevelop (window opens then shuts down).
Other than that F# seems to work fine, I can run console programs without any problem.
I also tried to run a simple HelloWorld program with C# in MonoDevelop, and it just works fine.
Any tips?
You need to start the forms event loop with something like
Application.Run(new Form())
Related
Things that i should note are that I am using the latest version of vs code to write in c, my compiler is mingw-w64. Whenever I run a simple code (Hello world for example) everything works then suddendly when I try to do something else a message appears saying (program name).exe was not found. This generally happens when I try to use commands from other libraries, i tries using conio.h textcolor() but it doesn't want to, but when i use getch() it works fine. Moreover the .exe file exists, then i add a single line of code and boom suddendly it doesn't exist. Can anyone explain to me what is going on??
I followed the instructions in this video:(See Docs)
What happened is that I created a very basic program in C, here is the code:
#include <stdio.h>
int main()
{
printf("Hey Buddy!\n");
return 0;
}
I compiled it using Mingw and an .exe file was created. Here the problem begins...
When simply opening the file in windows, a cmd window that says "Hey Buddy!" opens and closes immediately.
When trying to run the .exe file using the command line, the same thing happens, but the command line window then becomes stuck and it is impossible to close it - only shutting off the computer can do it.
Your help would be very appreciated, and I am sorry if I am doing something dumb and not realizing it:)
Your program is fine. The main declaration is wrong. It should be
int main(void)
but the declaration in your question won't cause any problems. I'm just telling you this to set you off on the right path.
Of course when you double click on the executable, then a new console window appears and immediately disappears. The program prints a single line of text and returns immediately. That behaviour is as expected.
The problem with the console window that cannot be closed is not down to an error in your code, at least the code that is shown in the question cannot explain that. That is presumably an environmental problem with your machine and/or compiler installation. Or perhaps you just have not yet worked out how to close a console window.
So I wrote a POSIX Threads application in C (linux) in which you get as command line args the number of threads , and the filename which the threads will work on.It works.
Now I also need to make it work in windows.
I've changed all the necessary names and headers , but since I'm trying to do it in VS2012 , I don't know how to get the Debugger output.
printf does not work , obviously , so what can I use instead ?
The code is included in a C++ WinConsoleApp project.
You can use OutputDebugString function, but the VS output window should work only for debugger output. For console output, you should create Windows 32 Console Application project.
Other way is to allocate console yourself:
AllocConsole();
freopen("CONIN$", "r",stdin);
freopen("CONOUT$", "w",stdout);
freopen("CONOUT$", "w",stderr);
I'll try to be simple and quick
I'm developing a program, a windows form actually.
I have a pictureBox and in the following line, when I run in debug mode(note that), I get an System.IO.FileNotFoundException exception:
pictureBox1->Image = Image::FromFile(".\\images\\no-avatar2.jpg");
The problem is that I don't get that exception when I run the exe file AND the file loads perfectly.
Any ideas why this happens?
I use this:
pictureBox1->Image = Image::FromFile(System::IO::Path::GetDirectoryName(System::Reflection::Assembly::GetEntryAssembly()->Location) + "\\images\\no-avatar2.jpg");
and it works perfectly
I want to start a simple program when windows start but I don't want to show the console output window associated with that program. Just to test, the program can be as simple as:
int main (int argc, char** argv)
{
while (1)
{
printf ("hello world...\n");
Sleep (10000);
}
return 0;
}
compiling it as: cl foo.c
I know how to start the program when windows is starting (putting in startup folder, creating registry etc), but I don't know how to hide the console output window that comes when the program is started.
While searching for this, I found that I can use start /B foo.exe. Is there any other method for doing this? some thing like "&" we use on unix.
My actual program is big and is written in C, so I can not use some other alternatives i found for c# (like WinMain) and java (like explained here).
This should work.
#include <windows.h>
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdParam, int iCmdShow)
{
for (;;) {
//action here
}
return 0;
}
WinMain is not a C# entry point. C# uses a method of a static class; it is called Main by default, but can be configured to any static-class method.
In Windows, non-console C programs should define a WinMain. You can then link them using the linker's /subsystem:windows command-line option, invokable either directly or from CL.
One method is calling FreeConsole() as first thing in main. It will hide the console window, if any.
Unfortunately simply setting FreeConsole() as the first function in main allows the window to appear momentarily anyway. And FreeConsole removes the window so that if you wish to use it later( as in killing the process ) you have to make it appear on screen in a mode out of your control.
Windows allows Win32 programs to have only one of four contexts under Visual Studio: Window program with initial GUI window, Console program with initial Console window, DLL or Lib. Changing the subsystem to a non-Console choice from the project->Properties->System view only results in linking issues that block the build.
Here is what worked for me with only a little effort. Use Mike's approach above and choose Win32 Project with Window Application. Then delete everything in WinMain after the "Place code here" direction and delete all the called functions. Return true or 1, as you wish from WinMain. No window of any type will appear on launch.
And when you are ready to deal with a Console Window call AllocConsole() in your code and deal with its positioning and size as you see fit. The Console can be positioned off screen and slid into view if you wish; it only takes a few minutes to get the handle on the configuring functions. Start with Microsoft's 'Console Functions' in MSDN documents. Unfortunately, there is no book on how to use all the functions properly as there is for NCurses in Linux.
When you're creating your project create one with WinMain instead ( Win32 Project ). If you still want the console later use AllocConsole() and FreeConsole().
If the program would be eg procexp.exe you can do this out of the box :
cmd /c "start C:\Users\denni\OneDrive\_bin\_tools\ProcessExplorer\procexp.exe"
WinMain isn't unique to C#. It's possible to write GUI applications in C too. The WinMain function is the entry point, but nothing says you have to actually create a window. You could have WinMain do nothing more than call the first function of your program to get it started. Then you'd have your program running with no GUI window and no console window.
Of course, this also means no easy way to stop it, short of killing it from Task Manager.