Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added build configurations for non-console windows application (i.e. invisible blat for scripting) #2

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

zwartetoorts
Copy link

And moved to VS2015.

I'm using blat to send mail from my ms access database application in vba. Sending multiple mails leaves the computer unusable with many console windows popping up, preventing me from doing something else because the frozen console windows keep forcing to the focus.

Signed-off-by: Okkel Klaver [email protected]

* Added build configurations for non-console windows application (i.e. invisible blat)

Signed-off-by: Okkel Klaver <[email protected]>
@tbeu
Copy link
Owner

tbeu commented Jan 3, 2016

If I understand your changes correctly the relevant difference is the linker option /SUBSYSTEM:WINDOWS where it previously was /SUBSYSTEM:CONSOLE, right? Actually I am not sure if this should be the default option such we can omit your newly created configurations.

I am also not sure if we will update to VS2015 if it will break the build with VS2010.

I add @ChipProgrammer as the main developer of blat.

@zwartetoorts
Copy link
Author

Along with /ENTRY:wmainCRTStartup, /SUBSYSTEM:WINDOWS and preprocessor
definitions (changing _CONSOLE to _WINDOWS) there isn't much change.
It's more like adding more build options to people using blat, as it was
the first reason for me to look into this matter.
Like java providing javaw and java exe choices.

Op 03-01-16 om 23:10 schreef tbeu:

If I understand your changes correctly the relevant difference is the
linker option |/SUBSYSTEM:WINDOWS| where it previously was
|/SUBSYSTEM:CONSOLE|, right? Actually I am not sure if this should be
the default option such we can omit your newly created configurations.

I am also not sure if we will update to VS2015 if it will break the
build with VS2010.

I add @ChipProgrammer https://github.com/ChipProgrammer as the main
developer of blat.


Reply to this email directly or view it on GitHub
#2 (comment).

@ChipProgrammer
Copy link
Collaborator

Is it possible to use blat.dll to send emails instead of using blat.exe? This should prevent console windows from opening. I do not know the answer because I do not use VBA.

In addition, does the VBA script give Blat the needed message body, either as a file name or by using the -body option?

Chip

@zwartetoorts
Copy link
Author

I think it should be possible in VBA to send using blat.dll. Haven't
looked into it, but I know you can call system libraries from VBA. I
don't like using it, but then again - I don't like VBA at all.
Calling blat.exe is much easier, just call WshShell.exec(). I'm reading
from stout to log blat output. The popup console window stays empty.
blat command line example: "X:\DataBases\blat.exe"
"X:\DataBases\Email\template.html" -to [email protected] -attach
"X:\DataBases\Email\ 34655.pdf" -embed "X:\DataBases\Email\logo.jpg"
-subject "Rekening Januari 2016"

Met vriendelijke groet,
Okkel Klaver,
Van het Land

Op 4-1-2016 om 2:41 schreef ChipProgrammer:

Is it possible to use blat.dll to send emails instead of using
blat.exe? This should prevent console windows from opening. I do not
know the answer because I do not use VBA.

In addition, does the VBA script give Blat the needed message body,
either as a file name or by using the -body option?

Chip


Reply to this email directly or view it on GitHub
#2 (comment).

@ChipProgrammer
Copy link
Collaborator

Making these changes, /ENTRY:wmainCRTStartup, /SUBSYSTEM:WINDOWS and preprocessor definitions (changing _CONSOLE to _WINDOWS), do you still get open console windows when running your VBA program?

Chip

@zwartetoorts
Copy link
Author

Nope, only /SUBSYSTEM:CONSOLE applications get the open console window.
Even before the application actually starts.
With these modifications blat is a 'normal' windows application. (and
thus invisible when called from scripts).

Met vriendelijke groet,
Okkel Klaver,
Van het Land

Op 4-1-2016 om 20:25 schreef ChipProgrammer:

Making these changes, /ENTRY:wmainCRTStartup, /SUBSYSTEM:WINDOWS and
preprocessor definitions (changing _CONSOLE to _WINDOWS), do you still
get open console windows when running your VBA program?

Chip


Reply to this email directly or view it on GitHub
#2 (comment).

@ChipProgrammer
Copy link
Collaborator

My main concern is for batch files, that these will wait for Blat to finish before continuing. If this works as before, then Blat's return value can still be checked. My testing with your changes, but without /ENTRY (this is the default anyway), shows my test batch works just like before.

Thank you,
Chip

@zwartetoorts
Copy link
Author

VBA waits for blat to finish, so I would expect batch files to do so
likewise.
I believe if you specify /SUBSYSTEM:WINDOWS the linker expects a
WinMain(). Since blat is a console application it doesn't have a
WinMain(), but main().
That's why /ENTRY:wmainCRTStratup is needed.
At least, that was the trouble I had to go through to get blat to build.

Met vriendelijke groet,
Okkel Klaver,
Van het Land

Op 04-01-16 om 21:50 schreef ChipProgrammer:

My main concern is for batch files, that these will wait for Blat to
finish before continuing. If this works as before, then Blat's return
value can still be checked. My testing with your changes, but without
/ENTRY (this is the default anyway), shows my test batch works just
like before.

Thank you,
Chip


Reply to this email directly or view it on GitHub
#2 (comment).

@ChipProgrammer
Copy link
Collaborator

I removed "/subsystem:console" from the link line, and have not seen any problems with the link or at run time.

Chip

@zwartetoorts
Copy link
Author

When I alter the subsystem to 'not set' and remove the entry point blat
builds at a console application again.
When you execute blat, don't you get the black console window?

Met vriendelijke groet,
Okkel Klaver,
Van het Land

Op 6-1-2016 om 0:19 schreef ChipProgrammer:

I removed "/subsystem:console" from the link line, and have not seen
any problems with the link or at run time.

Chip


Reply to this email directly or view it on GitHub
#2 (comment).

@ChipProgrammer
Copy link
Collaborator

The problem with making the changes you suggest is that Blat's console output does not work. If you were to give Blat an invalid command line option, you (the user) would not know because that information is no longer available.

I will continue to build Blat as a console application, and I will resubmit updated build files to make sure this continues.

Chip

@zwartetoorts
Copy link
Author

I wasn't suggesting to change anything, but adding a build configuration
to build blat as a windows application.
Console output can still be read by scripts in the windows build. I'm
actually using it to log all blat output.
It perfectly clear blat has to be a console application, for the reasons
you mentioned, but when using in a production environment it's nice to
be able to choose a build that doesn't popup a console window. (Wich in
my case actually stays empty, as I'm redirecting all output to my log
files.)

Met vriendelijke groet,
Okkel Klaver,
Van het Land

Op 8-1-2016 om 6:40 schreef ChipProgrammer:

The problem with making the changes you suggest is that Blat's console
output does not work. If you were to give Blat an invalid command line
option, you (the user) would not know because that information is no
longer available.

I will continue to build Blat as a console application, and I will
resubmit updated build files to make sure this continues.

Chip


Reply to this email directly or view it on GitHub
#2 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants