BarTender project - exporting printer code templates - Follow-up
up vote
0
down vote
favorite
This is a follow up to a previous question
previous question: BarTender project with C# - exporting printer code templates
From the first edit to this, I have changed the program use less of a procedural approach. Is this too much? When do you start breaking things into a separate class?
I feel like I'm stretching to make the bottom functions (but at the same time, it is a lot easier to read)
using System;
namespace BarTender
{
class btExport
{
// Used for manual input
static private string input = null;
static private string output = null;
// Dummy Variable
private const string DataExportPath = "";
// Declare a BarTender application variable
static private BarTender.Application bartenderApp;
// Declare a BarTender document variable
static private BarTender.Format format;
// Declare a BarTender printer code template variable
static private BarTender.PrinterCodeTemplate printerCodeTemplate;
// Declare an object variable
static private System.Object obj = null;
static void Main(string args)
{
///////////////////////////////////////////
/* START OF BARTENDER SIDE */
///////////////////////////////////////////
// Only start BarTender when needed, otherwise use old instances
try
{
// Store this instance as an object variable in C#
object newBtApp = System.Runtime.InteropServices.Marshal.GetActiveObject("BarTender.Application");
// Convert the object variable to a BarTender application variable
bartenderApp = newBtApp as BarTender.Application;
}
catch
{
bartenderApp = new BarTender.Application();
}
// Set the BarTender application visible
bartenderApp.Visible = true;
////////////////////////////////////////
/* START LOGIC */
////////////////////////////////////////
// If run without parameters this 'if' is triggered for manual entry
if (args.Length == 0)
{
manualInput();
}
// Taking parameters from Main
else
{
input = args[0];
Console.WriteLine("Input File Path:" + input);
output = args[1];
Console.WriteLine("Output File Path:" + output);
}
// Open a BarTender document
openBartenderDoc();
// End the BarTender process
bartenderApp.Quit(BarTender.BtSaveOptions.btDoNotSaveChanges);
Console.WriteLine("Complete");
}
/////////////////////////////////////////////////////
static private string manualInput()
{
int startForTrim = 0;
Console.WriteLine("No parameters specified. n Enter manually or try again.");
Console.Write("Input: ");
input = Console.ReadLine();
startForTrim = input.Length - 4;
output = input.Remove(startForTrim, 4);
output = output += "prn"";
Console.WriteLine(output);
return output;
}
static private void openBartenderDoc()
{
try
{
format = bartenderApp.Formats.Open(""" + input + """, false, "");
// Specify the password to remove print-only protection from the application
bartenderApp.SpecifyPrintOnlyPassword("#Betsy");
// Set the printer code template variable
printerCodeTemplate = format.PrinterCodeTemplate;
// Export the printer code template
printerCodeTemplate.Export("SAPscript-ITF", BarTender.BtPctExportType.btPctExportCombined, output, DataExportPath, ref obj);
}
catch { Console.WriteLine("Input or Export file does not exist."); Console.ReadLine(); return; }
}
}
}
c# beginner console
New contributor
add a comment |
up vote
0
down vote
favorite
This is a follow up to a previous question
previous question: BarTender project with C# - exporting printer code templates
From the first edit to this, I have changed the program use less of a procedural approach. Is this too much? When do you start breaking things into a separate class?
I feel like I'm stretching to make the bottom functions (but at the same time, it is a lot easier to read)
using System;
namespace BarTender
{
class btExport
{
// Used for manual input
static private string input = null;
static private string output = null;
// Dummy Variable
private const string DataExportPath = "";
// Declare a BarTender application variable
static private BarTender.Application bartenderApp;
// Declare a BarTender document variable
static private BarTender.Format format;
// Declare a BarTender printer code template variable
static private BarTender.PrinterCodeTemplate printerCodeTemplate;
// Declare an object variable
static private System.Object obj = null;
static void Main(string args)
{
///////////////////////////////////////////
/* START OF BARTENDER SIDE */
///////////////////////////////////////////
// Only start BarTender when needed, otherwise use old instances
try
{
// Store this instance as an object variable in C#
object newBtApp = System.Runtime.InteropServices.Marshal.GetActiveObject("BarTender.Application");
// Convert the object variable to a BarTender application variable
bartenderApp = newBtApp as BarTender.Application;
}
catch
{
bartenderApp = new BarTender.Application();
}
// Set the BarTender application visible
bartenderApp.Visible = true;
////////////////////////////////////////
/* START LOGIC */
////////////////////////////////////////
// If run without parameters this 'if' is triggered for manual entry
if (args.Length == 0)
{
manualInput();
}
// Taking parameters from Main
else
{
input = args[0];
Console.WriteLine("Input File Path:" + input);
output = args[1];
Console.WriteLine("Output File Path:" + output);
}
// Open a BarTender document
openBartenderDoc();
// End the BarTender process
bartenderApp.Quit(BarTender.BtSaveOptions.btDoNotSaveChanges);
Console.WriteLine("Complete");
}
/////////////////////////////////////////////////////
static private string manualInput()
{
int startForTrim = 0;
Console.WriteLine("No parameters specified. n Enter manually or try again.");
Console.Write("Input: ");
input = Console.ReadLine();
startForTrim = input.Length - 4;
output = input.Remove(startForTrim, 4);
output = output += "prn"";
Console.WriteLine(output);
return output;
}
static private void openBartenderDoc()
{
try
{
format = bartenderApp.Formats.Open(""" + input + """, false, "");
// Specify the password to remove print-only protection from the application
bartenderApp.SpecifyPrintOnlyPassword("#Betsy");
// Set the printer code template variable
printerCodeTemplate = format.PrinterCodeTemplate;
// Export the printer code template
printerCodeTemplate.Export("SAPscript-ITF", BarTender.BtPctExportType.btPctExportCombined, output, DataExportPath, ref obj);
}
catch { Console.WriteLine("Input or Export file does not exist."); Console.ReadLine(); return; }
}
}
}
c# beginner console
New contributor
2
See my answer to your previous post - several points still apply to this version. Specific to this version, using static fields to 'communicate' between methods makes it difficult to see how they depend on each other. It's better to use parameters and return values instead (more descriptive, dependencies are more visible, and it's more difficult to use the code incorrectly). Variables that are only used in one method should be local variables, not fields.
– Pieter Witvoet
10 hours ago
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
This is a follow up to a previous question
previous question: BarTender project with C# - exporting printer code templates
From the first edit to this, I have changed the program use less of a procedural approach. Is this too much? When do you start breaking things into a separate class?
I feel like I'm stretching to make the bottom functions (but at the same time, it is a lot easier to read)
using System;
namespace BarTender
{
class btExport
{
// Used for manual input
static private string input = null;
static private string output = null;
// Dummy Variable
private const string DataExportPath = "";
// Declare a BarTender application variable
static private BarTender.Application bartenderApp;
// Declare a BarTender document variable
static private BarTender.Format format;
// Declare a BarTender printer code template variable
static private BarTender.PrinterCodeTemplate printerCodeTemplate;
// Declare an object variable
static private System.Object obj = null;
static void Main(string args)
{
///////////////////////////////////////////
/* START OF BARTENDER SIDE */
///////////////////////////////////////////
// Only start BarTender when needed, otherwise use old instances
try
{
// Store this instance as an object variable in C#
object newBtApp = System.Runtime.InteropServices.Marshal.GetActiveObject("BarTender.Application");
// Convert the object variable to a BarTender application variable
bartenderApp = newBtApp as BarTender.Application;
}
catch
{
bartenderApp = new BarTender.Application();
}
// Set the BarTender application visible
bartenderApp.Visible = true;
////////////////////////////////////////
/* START LOGIC */
////////////////////////////////////////
// If run without parameters this 'if' is triggered for manual entry
if (args.Length == 0)
{
manualInput();
}
// Taking parameters from Main
else
{
input = args[0];
Console.WriteLine("Input File Path:" + input);
output = args[1];
Console.WriteLine("Output File Path:" + output);
}
// Open a BarTender document
openBartenderDoc();
// End the BarTender process
bartenderApp.Quit(BarTender.BtSaveOptions.btDoNotSaveChanges);
Console.WriteLine("Complete");
}
/////////////////////////////////////////////////////
static private string manualInput()
{
int startForTrim = 0;
Console.WriteLine("No parameters specified. n Enter manually or try again.");
Console.Write("Input: ");
input = Console.ReadLine();
startForTrim = input.Length - 4;
output = input.Remove(startForTrim, 4);
output = output += "prn"";
Console.WriteLine(output);
return output;
}
static private void openBartenderDoc()
{
try
{
format = bartenderApp.Formats.Open(""" + input + """, false, "");
// Specify the password to remove print-only protection from the application
bartenderApp.SpecifyPrintOnlyPassword("#Betsy");
// Set the printer code template variable
printerCodeTemplate = format.PrinterCodeTemplate;
// Export the printer code template
printerCodeTemplate.Export("SAPscript-ITF", BarTender.BtPctExportType.btPctExportCombined, output, DataExportPath, ref obj);
}
catch { Console.WriteLine("Input or Export file does not exist."); Console.ReadLine(); return; }
}
}
}
c# beginner console
New contributor
This is a follow up to a previous question
previous question: BarTender project with C# - exporting printer code templates
From the first edit to this, I have changed the program use less of a procedural approach. Is this too much? When do you start breaking things into a separate class?
I feel like I'm stretching to make the bottom functions (but at the same time, it is a lot easier to read)
using System;
namespace BarTender
{
class btExport
{
// Used for manual input
static private string input = null;
static private string output = null;
// Dummy Variable
private const string DataExportPath = "";
// Declare a BarTender application variable
static private BarTender.Application bartenderApp;
// Declare a BarTender document variable
static private BarTender.Format format;
// Declare a BarTender printer code template variable
static private BarTender.PrinterCodeTemplate printerCodeTemplate;
// Declare an object variable
static private System.Object obj = null;
static void Main(string args)
{
///////////////////////////////////////////
/* START OF BARTENDER SIDE */
///////////////////////////////////////////
// Only start BarTender when needed, otherwise use old instances
try
{
// Store this instance as an object variable in C#
object newBtApp = System.Runtime.InteropServices.Marshal.GetActiveObject("BarTender.Application");
// Convert the object variable to a BarTender application variable
bartenderApp = newBtApp as BarTender.Application;
}
catch
{
bartenderApp = new BarTender.Application();
}
// Set the BarTender application visible
bartenderApp.Visible = true;
////////////////////////////////////////
/* START LOGIC */
////////////////////////////////////////
// If run without parameters this 'if' is triggered for manual entry
if (args.Length == 0)
{
manualInput();
}
// Taking parameters from Main
else
{
input = args[0];
Console.WriteLine("Input File Path:" + input);
output = args[1];
Console.WriteLine("Output File Path:" + output);
}
// Open a BarTender document
openBartenderDoc();
// End the BarTender process
bartenderApp.Quit(BarTender.BtSaveOptions.btDoNotSaveChanges);
Console.WriteLine("Complete");
}
/////////////////////////////////////////////////////
static private string manualInput()
{
int startForTrim = 0;
Console.WriteLine("No parameters specified. n Enter manually or try again.");
Console.Write("Input: ");
input = Console.ReadLine();
startForTrim = input.Length - 4;
output = input.Remove(startForTrim, 4);
output = output += "prn"";
Console.WriteLine(output);
return output;
}
static private void openBartenderDoc()
{
try
{
format = bartenderApp.Formats.Open(""" + input + """, false, "");
// Specify the password to remove print-only protection from the application
bartenderApp.SpecifyPrintOnlyPassword("#Betsy");
// Set the printer code template variable
printerCodeTemplate = format.PrinterCodeTemplate;
// Export the printer code template
printerCodeTemplate.Export("SAPscript-ITF", BarTender.BtPctExportType.btPctExportCombined, output, DataExportPath, ref obj);
}
catch { Console.WriteLine("Input or Export file does not exist."); Console.ReadLine(); return; }
}
}
}
c# beginner console
c# beginner console
New contributor
New contributor
edited 8 mins ago
t3chb0t
33.8k746110
33.8k746110
New contributor
asked 10 hours ago
C. Catt
83
83
New contributor
New contributor
2
See my answer to your previous post - several points still apply to this version. Specific to this version, using static fields to 'communicate' between methods makes it difficult to see how they depend on each other. It's better to use parameters and return values instead (more descriptive, dependencies are more visible, and it's more difficult to use the code incorrectly). Variables that are only used in one method should be local variables, not fields.
– Pieter Witvoet
10 hours ago
add a comment |
2
See my answer to your previous post - several points still apply to this version. Specific to this version, using static fields to 'communicate' between methods makes it difficult to see how they depend on each other. It's better to use parameters and return values instead (more descriptive, dependencies are more visible, and it's more difficult to use the code incorrectly). Variables that are only used in one method should be local variables, not fields.
– Pieter Witvoet
10 hours ago
2
2
See my answer to your previous post - several points still apply to this version. Specific to this version, using static fields to 'communicate' between methods makes it difficult to see how they depend on each other. It's better to use parameters and return values instead (more descriptive, dependencies are more visible, and it's more difficult to use the code incorrectly). Variables that are only used in one method should be local variables, not fields.
– Pieter Witvoet
10 hours ago
See my answer to your previous post - several points still apply to this version. Specific to this version, using static fields to 'communicate' between methods makes it difficult to see how they depend on each other. It's better to use parameters and return values instead (more descriptive, dependencies are more visible, and it's more difficult to use the code incorrectly). Variables that are only used in one method should be local variables, not fields.
– Pieter Witvoet
10 hours ago
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
C. Catt is a new contributor. Be nice, and check out our Code of Conduct.
C. Catt is a new contributor. Be nice, and check out our Code of Conduct.
C. Catt is a new contributor. Be nice, and check out our Code of Conduct.
C. Catt is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209472%2fbartender-project-exporting-printer-code-templates-follow-up%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
See my answer to your previous post - several points still apply to this version. Specific to this version, using static fields to 'communicate' between methods makes it difficult to see how they depend on each other. It's better to use parameters and return values instead (more descriptive, dependencies are more visible, and it's more difficult to use the code incorrectly). Variables that are only used in one method should be local variables, not fields.
– Pieter Witvoet
10 hours ago