Can someone please help me with this, am trying to use OpenFileDialog class from System.Windows.Forms to open a file dialog and read the selected file. Then, this error showed up. I've referenced it but still the same, below is the code.
`using UnityEngine
using UnityEngine.UI
using System.Windows.Forms;
public class OpenFileButtonScript : MonoBehaviour
{
public TextFieldScript textFieldScript;
public void OpenFile()
{
OpenFileDialog openFileDialog = new OpenFileDialog();
openFileDialog.Filter = "Text Files (*.txt)|*.txt|All Files (*.*)|*.*";
openFileDialog.FilterIndex = 1;
openFileDialog.Multiselect = false;
if (openFileDialog.ShowDialog() == DialogResult.OK)
{
string filePath = openFileDialog.FileName;
string text = System.IO.File.ReadAllText(filePath);
textFieldScript.inputField.text = text;
}
}
}`
It may look like you have access to all of the native Window system libraries, but it just looks like it. In actuality, a lot of the time you're simply given stubs, or shims, that look like the full Window libraries, because there's a certain element that Unity wants to use from those namespaces. If you think about it, the code you present above, what do you think it should do on Android or Nintendo devices? The simple answer is, it simply won't work.
Generally in cases like this, you have to gain access to the native operating system, and perform those calls directly. For example, there is a file browser asset on the Asset Store, that does this for you. It's not free, because the process isn't trivial.
Depending on how much effort you want to put in, you CAN read files from the local file stores (to varying degrees based on platform). It's possible to read the list of files in a location, and use either uGUI or UIToolkit to create your own File Open Dialogue box. Again, this isn't a trivial task either. So you have to be sure that you'd want to go down that path.
I have a number of WPF dialogs in my Word Add-In. For one of them (and only one, strangely), it is sometimes not focused when opened. I believe I need to set its parent.
I know there is a way to set the owner of a WPF window to a HWND, but is there any way to get a HWND in Word 2010? I found this HWND property but it is Word 2013 and later only. Is there any other way to get Word's HWND, other than using GetForegroundWindow() which does not guarantee the handle for the window I actually want (or any other similar kludge)?
I found something helpful in Get specific window handle using Office interop. But all those answers are based on getting the handle for a window you're newly creating. I modified it somewhat to get an existing window, and stuffed it into a utility method.
doc is the current document.
using System.Windows.Interop;
using System.Diagnostics;
public void SetOwner(System.Windows.Window pd)
{
var wordProcs = Process.GetProcessesByName("winword").ToList();
// in read-only mode, this would be e.g. "1.docx [Read-Only] - Microsoft Word"
var procs = wordProcs.Where(x =>
x.MainWindowTitle.StartsWith(Path.GetFileName(doc.FullName))
&&
x.MainWindowTitle.EndsWith("- Microsoft Word"));
if (procs.Count() >= 1)
{
// would prefer Word 2013's Window.HWND property for this
var handle = procs.First().MainWindowHandle;
WindowInteropHelper wih = new WindowInteropHelper(pd);
wih.Owner = handle;
}
}
Unfortunately it doesn't seem to be possible to account for multiple windows with the same document name (in different folders), because the number of processes is never greater than 1. But I think that's an acceptable limitation.
for some reason when I try to use scanner with gwt, i get the following error:
No source code is available for type java.util.Scanner; did you forget to inherit a required module?
I looked around and it seems the "No source code is available for type xxxx" errors are due to not having a Javascript equivalent type for the Java type.
Is scanner not able to be used with GWT?
Here is a snippet of my code:
import java.util.Scanner;
...
public void submit(){
String text = editor.getEditor().getText();
Scanner input = new Scanner(text);
while(input.hasNextLine()){
String line = input.nextLine();
if(line.contains("//")){
cInfo.setDone(false);
cInfo.setCode(text);
return;
}
cInfo.setDone(true);
cInfo.setCode(text);
}
}
}
java.util.Scanner is not part of the GWT JRE Emulation. If you need a detail overview of what is inside the emulation here is the link to the docs:
https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation#Package_java_util
Your code (at least the one in the current version of your question) is probably[*] equivalent to
public void submit() {
String text = editor.getEditor().getText();
if ("".equals(text))
return;
cInfo.setDone(!text.contains("//"));
cInfo.setCode(text);
}
However, I have a feeling that this may not actually be what want to do (or is it?)
If you need to split strings on the client side, I usually recommend the Splitter class in Guava. Most of its methods are GwtCompatible, and (together with CharMatcher, Joiner, ...) it's great to use both on the client and server side of your Java code.
[*] assuming, that setDone and setCode are simple setters without side effects
I need to work in .net 2.0. So I can't use OpenXML.
This is my source code and I have already Installed AccessDatabaseEngine.exe.
But still getting the exception:
"Could not find installable ISAM".
I have also tried "Extended Properties=Excel 8.0" in the connection string.
static void Main(string[] args)
{
DataSet dataSet = new DataSet();
OleDbConnection connection = new OleDbConnection(#"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|Data Directory|\HSC.xlsx;Extended Properties=Excel 12.0;HDR=YES;");
OleDbDataAdapter dataAdapter= new OleDbDataAdapter("select * from [Sheet1$]", connection);
dataAdapter.Fill(dataSet);
}
According to Carl Prothman, that should be
Extended Properties="Excel 12.0 Xml;
-- http://www.connectionstrings.com/excel-2007
In more detail:
OleDbConnection connection = new OleDbConnection(#"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\Docs\\Book2.xlsx;Extended Properties='Excel 12.0 xml;HDR=YES;'");
Note the single quotes.
I prefer to use the Microsoft OpenXML 2.0 SDK for this kind of functionality. It has a really nice interface, and it does not put a demand on having Office installed on the machine reading the XLSX file which is a good thing.
I'm writing this from my mobile, so hard to provide a link, but a Google search should easily find it for you.
Give it a try. I think you will like it.
EDIT
If you have to use .NET 2.0, you can go for using the JET variant of the OleDb instead.
That means you will do something like this to connect:
OleDbConnection connection = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;" +
"Data Source='" + filename + "';" +
"Extended Properties=\"Excel 8.0;HDR=No;IMEX=1;\"";);
Then you can query it like in your example above:
OleDbDataAdapter objAdapter = new OleDbDataAdapter("select * from [Sheet1$]", connection);
Try it! Just note that Jet have some strange logic of deciding if a column is numeric or not. See the following SO questions for details: Problem with using OleDbDataAdapter to fetch data from a Excel sheet
You should make sure that the connection string looks like the following ( even if you are accessing microsoft excel version 10 ->
MyConnection = new System.Data.OleDb.OleDbConnection(#"Provider=Microsoft.ACE.OLEDB.12.0;
Data Source='D:\csharp-Excel.xls';Extended Properties='Excel 12.0 Xml;HDR=Yes;'");
I am redesigning a command line application and am looking for a way to make its use more intuitive. Are there any conventions for the format of parameters passed into a command line application? Or any other method that people have found useful?
I see a lot of Windows command line specifics, but if your program is intended for Linux, I find the GNU command line standard to be the most intuitive. Basically, it uses double hyphens for the long form of a command (e.g., --help) and a single hyphen for the short version (e.g., -h). You can also "stack" the short versions together (e.g., tar -zxvf filename) and mix 'n match long and short to your heart's content.
The GNU site also lists standard option names.
The getopt library greatly simplifies parsing these commands. If C's not your bag, Python has a similar library, as does Perl.
If you are using C# try Mono.GetOptions, it's a very powerful and simple-to-use command-line argument parser. It works in Mono environments and with Microsoft .NET Framework.
EDIT: Here are a few features
Each param has 2 CLI representations (1 character and string, e.g. -a or --add)
Default values
Strongly typed
Automagically produces an help screen with instructions
Automagically produces a version and copyright screen
One thing I like about certain CLI is the usage of shortcuts.
I.e, all the following lines are doing the same thing
myCli.exe describe someThing
myCli.exe descr someThing
myCli.exe desc someThing
That way, the user may not have to type the all command every time.
A good and helpful reference:
https://commandline.codeplex.com/
Library available via NuGet:
Latest stable: Install-Package CommandLineParser.
Latest release: Install-Package CommandLineParser -pre.
One line parsing using default singleton: CommandLine.Parser.Default.ParseArguments(...).
One line help screen generator: HelpText.AutoBuild(...).
Map command line arguments to IList<string>, arrays, enum or standard scalar types.
Plug-In friendly architecture as explained here.
Define verb commands as git commit -a.
Create parser instance using lambda expressions.
QuickStart: https://commandline.codeplex.com/wikipage?title=Quickstart&referringTitle=Documentation
// Define a class to receive parsed values
class Options {
[Option('r', "read", Required = true,
HelpText = "Input file to be processed.")]
public string InputFile { get; set; }
[Option('v', "verbose", DefaultValue = true,
HelpText = "Prints all messages to standard output.")]
public bool Verbose { get; set; }
[ParserState]
public IParserState LastParserState { get; set; }
[HelpOption]
public string GetUsage() {
return HelpText.AutoBuild(this,
(HelpText current) => HelpText.DefaultParsingErrorsHandler(this, current));
}
}
// Consume them
static void Main(string[] args) {
var options = new Options();
if (CommandLine.Parser.Default.ParseArguments(args, options)) {
// Values are available here
if (options.Verbose) Console.WriteLine("Filename: {0}", options.InputFile);
}
}
Best thing to do is don't assume anything if you can. When the operator types in your application name for execution and does not have any parameters either hit them with a USAGE block or in the alternative open a Windows Form and allow them to enter everything you need.
c:\>FOO
FOO
USAGE FOO -{Option}{Value}
-A Do A stuff
-B Do B stuff
c:\>
Parameter delimiting I place under the heading of a religious topic: hyphens(dashes), double hyphens, slashes, nothing, positional, etc.
You didn't indicate your platform, but for the next comment I will assume Windows and .net
You can create a console based application in .net and allow it to interact with the Desktop using Forms just by choosing the console based project then adding the Windows.Forms, System.Drawing, etc DLLs.
We do this all the time. This assures that no one takes a turn down a dark alley.
Command line conventions vary from OS to OS, but the convention that's probably gotten both the most use, and the most public scrutiny is the one supported by the GNU getopt package. See http://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html for more info.
It allows you to mix single letter commands, such as -nr, with longer, self-documenting options, such as --numeric --reverse. Be nice, and implement a --help (-?) option and then your users will be able to figure out all they need to know.
Here's a CodeProject article that might help you out...
C#/.NET Command Line Arguments Parser
IF VB is your flavor, here's a separate article (with a bit more guidance related content) to check out...
Parse and Validate Command Line Parameters with VB.NET
Complementing #vonc's answer, don't accept ambiguous abbreviations. Eg:
myCli.exe describe someThing
myCli.exe destroy someThing
myCli.exe des someThing ???
In fact, in that case, I probably wouldn't accept an abbreviation for "destroy"...
I always add a /? parameter to get help and I always try to have a default (i.e. most common scenario) implementation.
Otherwise I tend to use the "/x" for switches and "/x:value" for switches that require values to be passed. Makes it pretty easy to parse the parameters using regular expressions.
I developed this framework, maybe it helps:
The SysCommand is a powerful cross-platform framework, to develop Console Applications in .NET. Is simple, type-safe, and with great influences of the MVC pattern.
https://github.com/juniorgasparotto/SysCommand
namespace Example.Initialization.Simple
{
using SysCommand.ConsoleApp;
public class Program
{
public static int Main(string[] args)
{
return App.RunApplication();
}
}
// Classes inheriting from `Command` will be automatically found by the system
// and its public properties and methods will be available for use.
public class MyCommand : Command
{
public void Main(string arg1, int? arg2 = null)
{
if (arg1 != null)
this.App.Console.Write(string.Format("Main arg1='{0}'", arg1));
if (arg2 != null)
this.App.Console.Write(string.Format("Main arg2='{0}'", arg2));
}
public void MyAction(bool a)
{
this.App.Console.Write(string.Format("MyAction a='{0}'", a));
}
}
}
Tests:
// auto-generate help
$ my-app.exe help
// method "Main" typed
$ my-app.exe --arg1 value --arg2 1000
// or without "--arg2"
$ my-app.exe --arg1 value
// actions support
$ my-app.exe my-action -a
-operation [parameters] -command [your command] -anotherthings [otherparams]....
For example,
YourApp.exe -file %YourProject.prj% -Secure true
If you use one of the standard tools for generating command line interfaces, like getopts, then you'll conform automatically.
The conventions that you use for you application would depend on
1) What type of application it is.
2) What operating system you are using.
This is definitely true. I'm not certain about dos-prompt conventions, but on unix-like systems the general conventions are roughly:
1) Formatting is
appName parameters
2) Single character parameters (such as 'x') are passed as -x
3) Multi character parameters (such as 'add-keys') are passed as --add-keys
The conventions that you use for you application would depend on
1) What type of application it is.
2) What operating system you are using. Linux? Windows? They both have different conventions.
What I would suggest is look at other command line interfaces for other commands on your system, paying special attention to the parameters passed. Having incorrect parameters should give the user solution directed error message. An easy to find help screen can aid in usability as well.
Without know what exactly your application will do, it's hard to give specific examples.
If you're using Perl, my CLI::Application framework might be just what you need. It lets you build applications with a SVN/CVS/GIT like user interface easily ("your-command -o --long-opt some-action-to-execute some parameters").
I've created a .Net C# library that includes a command-line parser. You just need to create a class that inherits from the CmdLineObject class, call Initialize, and it will automatically populate the properties. It can handle conversions to different types (uses an advanced conversion library also included in the project), arrays, command-line aliases, click-once arguments, etc. It even automatically creates command-line help (/?).
If you are interested, the URL to the project is http://bizark.codeplex.com. It is currently only available as source code.
I've just released an even better command line parser.
https://github.com/gene-l-thomas/coptions
It's on nuget Install-Package coptions
using System;
using System.Collections.Generic;
using coptions;
[ApplicationInfo(Help = "This program does something useful.")]
public class Options
{
[Flag('s', "silent", Help = "Produce no output.")]
public bool Silent;
[Option('n', "name", "NAME", Help = "Name of user.")]
public string Name
{
get { return _name; }
set { if (String.IsNullOrWhiteSpace(value))
throw new InvalidOptionValueException("Name must not be blank");
_name = value;
}
}
private string _name;
[Option("size", Help = "Size to output.")]
public int Size = 3;
[Option('i', "ignore", "FILENAME", Help = "Files to ignore.")]
public List<string> Ignore;
[Flag('v', "verbose", Help = "Increase the amount of output.")]
public int Verbose = 1;
[Value("OUT", Help = "Output file.")]
public string OutputFile;
[Value("INPUT", Help = "Input files.")]
public List<string> InputFiles;
}
namespace coptions.ReadmeExample
{
class Program
{
static int Main(string[] args)
{
try
{
Options opt = CliParser.Parse<Options>(args);
Console.WriteLine(opt.Silent);
Console.WriteLine(opt.OutputFile);
return 0;
}
catch (CliParserExit)
{
// --help
return 0;
} catch (Exception e)
{
// unknown options etc...
Console.Error.WriteLine("Fatal Error: " + e.Message);
return 1;
}
}
}
}
Supports automatic --help generation, verbs, e.g. commmand.exe
Enjoy.