Re: Reading excel file in Vista x64 - C# Discussion Boards

Re: Is their a better way than using the Try/Catch statement in this source?

OriginalGriff1-Dec-09 9:15

OriginalGriff

1-Dec-09 9:15

Try doing a safe cast:

Xbox xb = prod as Xbox;
if (xb != null)
   {
   ...
   }

You could also use

if (prod is Xbox)
   {
   ...
   }

but the "as" cast will cope with nulls better.

[edit]Oops! put the <pre> tag in teh wrong place - fixed[/edit]

No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced.

This message is made of fully recyclable Zeros and Ones

"Rumour has it that if you play Microsoft CDs backwards you will hear Satanic messages.Worse still, is that if you play them forwards they will install Windows"

Re: Is their a better way than using the Try/Catch statement in this source?

venomation1-Dec-09 9:24

venomation

1-Dec-09 9:24

Awesome works very well, surprisingly i have came across this "as" syntax before and surprised i didnt think about it xD
Thanks Smile | :)

Re: Is their a better way than using the Try/Catch statement in this source?

OriginalGriff1-Dec-09 9:34

OriginalGriff

1-Dec-09 9:34

You're welcome.

Re: Is their a better way than using the Try/Catch statement in this source?

vtchris-peterson1-Dec-09 9:29

vtchris-peterson

1-Dec-09 9:29

Agreed that type-safe casting is far superior to blanket try/catch in the original code.

As for "as" vs. "is"... As far as I know, "as" and "is" both cope with nulls the same way, "as", however has an advantage when you need to use the instance through the casted type, i.e. you wouldn't want to do an "is" check only to then do an "as" cast after the fact.

In any event, you should consider exposing functionality common to both product types through the IProduct interface. Inheritence is only a useful design pattern when common functionality exists at certain levels of the type heirarchy -- if you constantly have to up and down cast, you're probably forcing a flawed design.

Re: Is their a better way than using the Try/Catch statement in this source?

venomation1-Dec-09 9:37

venomation

1-Dec-09 9:37

vtpdawg wrote:
any event, you should consider exposing functionality common to both product types through the IProduct interface. Inheritence is only a useful design pattern when common functionality exists at certain levels of the type heirarchy -- if you constantly have to up and down cast, you're probably forcing a flawed design.

I understand inheritance is only useful with common characteristics of data, this design was meant to be quick and rough test set-up so i can try and figure out my original problem. Thanks :P

Sandboxing with AppDomain

softwarejaeger1-Dec-09 7:51

softwarejaeger

1-Dec-09 7:51

Hello,

i want to restrict the file-access for the "IPlugin"-Object (except the same folder where the assembly is in), which i load over my AppDomain from another Assembly (which is in the same bin folder as the host-app).

But the "IPlugin"-Instance can write over "finder.PerformAction(null)" everywhere Oo what i'm doing wrong?

PermissionSet ps = new PermissionSet(PermissionState.None);
     ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
     FileIOPermission fP = new FileIOPermission(PermissionState.None);
     fP.AllFiles = FileIOPermissionAccess.NoAccess;
     fP.AddPathList(FileIOPermissionAccess.PathDiscovery | FileIOPermissionAccess.Read, Environment.CurrentDirectory);


     ps.AddPermission(fP);



         AppDomainSetup ads = new AppDomainSetup();
         ads.ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase;
         AppDomain domain = AppDomain.CreateDomain("Plugins", AppDomain.CurrentDomain.Evidence, ads, ps, CreateStrongName(System.Reflection.Assembly.GetExecutingAssembly()));
         IPlugin finder = (IPlugin)domain.CreateInstanceFromAndUnwrap("MyPluginTest.dll", "MyPluginTest.IPluginTest");
         finder.PerformAction(null);

Reading excel file in Vista x64

kmuthuk1-Dec-09 5:38

kmuthuk

1-Dec-09 5:38

I'm trying to read an Excel file in C# Visual Studio 2008 using oldDb. My connection gets opened successfully, but oldDb adapter doesn't fill the datatable.

Here is my code:

private void openExcel()
{
            string connectionString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=""C:\MyLocation\myFile.xls"";Extended Properties=""Excel 12.0;HDR=NO;""";
            OleDbConnection excelConnection = new OleDbConnection(connectionString);
            excelConnection.Open();

            string strSQL = "SELECT * FROM [Sheet1$]";

            OleDbCommand dbCommand = new OleDbCommand(strSQL, excelConnection);
            OleDbDataAdapter dataAdapter = new OleDbDataAdapter(dbCommand);

            // create data table
            DataTable dTable = new DataTable();
            dataAdapter.Fill(dTable);

            aListBoxControl.DataSource = dTable;

            // dispose used objects
            dTable.Dispose();
            dataAdapter.Dispose();
            dbCommand.Dispose();

            excelConnection.Close();
            excelConnection.Dispose();
        }

Could anyone please help me find this?

Thanks in advance.

Re: Reading excel file in Vista x64

Dave Kreskowiak1-Dec-09 5:47

Dave Kreskowiak

1-Dec-09 5:47

It's probably because your app is being compiled for "AnyCPU" instead of x86. There are no 64-bit drivers for this, and since you cannot mix 64 adn 32 bit code in the same process, you have to force your app to compile for x86 instead of AnyCPU.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Re: Reading excel file in Vista x64

kmuthuk1-Dec-09 5:55

kmuthuk

1-Dec-09 5:55

Thanks for the fast reply. It is x86. Moreover, dbCommand.ExecuteReader() does read the data.

Re: Reading excel file in Vista x64

Dave Kreskowiak1-Dec-09 11:04

Dave Kreskowiak

1-Dec-09 11:04

First, you do not have to open the connection first when using a DataAdapter. The DA will open and close the connection itself.

Second, instead of filling a DataTable, change this to use a DataSet instead. I've never done this with an Excel sheet, so there may be something funky going on that I don't know about.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Wrapped COM call works during Test, otherwise fails

puromtec11-Dec-09 5:18

puromtec1

1-Dec-09 5:18

I have an unusual situation.

A call from C# to C++ using static extern references to an un-mananged dll works perfectly during execution of TestClass/TestMethod unit testing within Visual Studio 2008. However, during debug (not during Testing) and normal execution, we receive an exception from the underlying COM object for which the C++ dll is a wrapper. And, right on queue, the third party COM object gives no detail why it failed.

I cannot much paste code because of proprietary reasons, however, here is the extern from C# which works fine under the context of unit testing (TestClass/TestMethod) in VS 2008.

[DllImport("BTDataAccess.dll")]
        static extern uint BTReadBu( [In, MarshalAs(UnmanagedType.BStr)] string filePath);

Few notes, we do have the c++/unmanaged copied to both the C# test project and console app. Additionally, the list of c# project refernces between test and console projects have been reviewed.

Any ideas regardless of how far out they are would be appreciated.

Re: Wrapped COM call works during Test, otherwise fails

Paulo Zemek1-Dec-09 6:07

Paulo Zemek

1-Dec-09 6:07

Have you tried changing calling convention:

[DllImport("BTDataAccess.dll", CallingConvention=CallingConvention.SomeCallingConvention)]

I already had problems when debugging/running by different calling conventions, as some exceptions are not thrown immediatelly on release code (but are still wrong). Maybe that's the case... maybe.

Try the charset also. I am only guessing, as I really don't know what is causing the problem.

Re: Wrapped COM call works during Test, otherwise fails

puromtec11-Dec-09 6:31

puromtec1

1-Dec-09 6:31

Thanks for the suggestion, however, none of the five CallingConvention enum values fixed the problem.

What do you mean by charset?

On another note, we are running this as a single-threaded operation. There is a call to the c++ unmanaged dll made prior to the one in question. However, it is tasks with simply instantiating a COM object. This first call and the second one which fails is performed on the same thread. Multi-threaded operations on COM brings a lot of issues, but this isn't the case here. I realize each unit test in VS is on its own thread, however, we rigged it that calls to the same COM object are not performed from different threads.

Re: Wrapped COM call works during Test, otherwise fails

Paulo Zemek1-Dec-09 8:06

Paulo Zemek

1-Dec-09 8:06

You use string. There is the CallingConvention and the CharSet properties.
Also, the calling convention can be wrong in the method that was called just before. So, if you instantiate a COM object and after call a method, is possible that the instantiation is using an invalid calling convention.

But, I am unsure... why you can't simple import your Com object by Visual Studio Add Referece? It creates the the available components with the right calling convention.

Re: Wrapped COM call works during Test, otherwise fails

puromtec11-Dec-09 8:45

puromtec1

1-Dec-09 8:45

Ok, the plot thickens.

A fellow developer wrote a bare-bones c# app that calls the c++ wrapper dll and it works from his computer. However, it fails from mine.

I tried each type of CharSet without success. Also, I tried it with callingconvention = CallingConvention.StdCall.

Btw, we used to use the automatically interop dll for calling the COM directly, however, it was very unstable. The funny thing is that stability is perfect with the approach using a hand-written c++ wrapper if called from c# under the context of visual studio unit testing.

help me to calculate the CRC!!

frommi1-Dec-09 5:04

frommi

1-Dec-09 5:04

Hi friends, my problem is to calculate the CRC value in the comunication between two terminal.
the string so composed:

10 02 (Start)
36 01 03 0e 57 00 00 00 29 00 00 (Data)
10 03 (End)
01 65 (CRC)

I already tried some CRC calculator but I have not found a correct calculation.
Can anyone give me some suggestions?
Thank you
Bye

Re: help me to calculate the CRC!!

Cracked-Down1-Dec-09 7:13

Cracked-Down

1-Dec-09 7:13

http://damieng.com/blog/2006/08/08/calculating_crc32_in_c_and_net
http://www.codeproject.com/KB/recipes/crc32_dotnet.aspx

Re: help me to calculate the CRC!!

harold aptroot1-Dec-09 7:24

harold aptroot

1-Dec-09 7:24

Probably not a CRC32, as it's only 2 bytes, but who knows..
Maybe Fletcher-16?

How to make single instance?

RanaSohail1-Dec-09 3:54

RanaSohail

1-Dec-09 3:54

hello all,

Application.Run(new Form1());
How can i start an application so that other instance don't start of the same application.

regard,
sohail

Re: How to make single instance?

mrcooll1-Dec-09 4:00

mrcooll

1-Dec-09 4:00

hi ,
have a look to this link it will help u
link

Re: How to make single instance?

PIEBALDconsult1-Dec-09 4:14

PIEBALDconsult

1-Dec-09 4:14

There are several articles here on CP that cover that in a number of ways.

Re: How to make single instance?

RanaSohail1-Dec-09 4:24

RanaSohail

1-Dec-09 4:24

mention please...! Smile | :)

Re: How to make single instance?

S. Brozius1-Dec-09 4:33

S. Brozius

1-Dec-09 4:33

Here you go : http://www.codeproject.com/info/search.aspx?artkw=single+instance+application[^]

Nah... What's up, Doc?
CCC's solved : 1

Re: How to make single instance?

David Skelly1-Dec-09 4:34

David Skelly

1-Dec-09 4:34

At the top of the page you will see a box labelled Search. Type single instance into this box. Select Articles / Quick Answers in the dropdown next to it. Click the Go! button.

Re: How to make single instance?

RanaSohail1-Dec-09 5:20

RanaSohail

1-Dec-09 5:20

Thanks you all Smile | :)

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.