|
Makes sense. Being an interface, marking it public would be redundant. Delete the keyword.
|
|
|
|
|
Thanks for the comment. I got rid of "public" so now it's
void iCR.initCRData(byte[] wrBuff, byte[] stBuffer, int slaveIndex, USB_Comm.CB cb_spec, int crType)
{}
However, I'm getting compilation errors indicating it's not being seen:
CR5_new.CR5 does not implement interface member iCR.initCRData(byte[], byte[], int, USB_Comm.CB, int)
iCR.initCRData in explicit interface declaration is not a member of interface
Any thoughts? On the one had it doesn't seem to see that it's there, but then it sees it and thinks it's not a part of the interface. This is what the interface VS project looks like,
public interface iCR
{
. . .
void initCRData(byte[] wrBuffer, byte[] stBuffer, int SlaveIndex, USB_Comm.ClearBox cb, int cr_Type);
. . .
}
My iCR dll is referenced in my CR5_new VS project. It could be something really basic, since I've only programmed with VS/C# for a little over 6 months...I have more C++ experience. Thanks for all of your help. I really appreciate it.
|
|
|
|
|
MichCl wrote: My iCR dll is referenced in my CR5_new VS project.
It's easier to "test" it in a separate console-app; create the desired structure there, isolated from the rest of your app.
Does it work if the interface and consuming class are in the same project? If yes, there's a problem with the reference (check namespaces, using-clauses etc) If no, there's a problem with the syntax.
This case, I'm guessing syntax. Compare your code to the example from MSDN[^].
|
|
|
|
|
It does work if the iCR, Factory class, Cr5, and El are in the same VS project, with the USB_Comm.CR class in a separate VS project.
It's weird...when I refer to the method in my CR5 project (the one we've been discussing), VS fills in the method I'm referring to, but when I try to get it to suggest the parameters I'm supposed to supply, it's not coming up with anything.
|
|
|
|
|
MichCl wrote: It does work if the iCR, Factory class, Cr5, and El are in the same VS project, with the USB_Comm.CR class in a separate VS project.
A syntax-error would have generated a compile-error. The fact that it works implies that the code is correct, and that it's a problem with the references.
Did you reference the project (add the project-source to the solution) or the assembly? Is there an old version of this assembly in the GAC?
Alternatively; what happens if you rename the interface? Does the exception pick up the correct new interface-name?
|
|
|
|
|
I figured it out... See below, after my response to your last post.
There are compilation errors with the VS project distributed as I first presented it. It's
CR5_new.CR5 does not implement interface member iCR.initCRData(...) (but it does)
and
iCR.initCRData in explicit interface declaration is not a member of interface (but it is)
I have a reference to the VS project iCR in my CR5_new project.
I'm not sure what you're referring to with GAC above. When I look in my CR5_new project, even though I see it referenced in the solution explorer under references, when I look in MyComputer, I don't see a copy of the dll, so presumably it's not a copy, it's actually looking for it in the original location. When I look at the Solution Explorer properties of iCR, it's giving the path to the correct original location for the dll.
Alternatively, when I change the name of the interface to iC from iCR, I had to change it in
public class CR5:iC in my CR5_new namespace/visual studio project. Plus I had to change it to iC.initCRData(...). Then the above compile errors changed to use the new interface name.
I figured it out when I was looking into the above... My CR5 project had another class in it for USB_Comm.CB. The iCR was also referring to this class for parameters in the interface. So they were cross-referencing. So I moved the USB_Comm.CB class into it's own VS project so they can both refer to it without cross-references.
On the one hand I feel like I'm not using multiple class VS projects, but if I kept these things in them, I'd have repeats of classes in my VS projects like El. Plus when I create my CR6 project, I can re-use code more. Thanks for all of your help!! 
|
|
|
|
|
MichCl wrote: I figured it out... See below, after my response to your last post.
Whehe, cool - and good explanation!
|
|
|
|
|
Hi All,
We are facing a critical issue in our application and I need your help in solving this issue:
Currently our application is communicating with Mainframes to get the Statements and we are using AFP2PDF converter to convert the AFP file format from Mainframes to the PDF format. The flow of the application is like :
.Net application --> stiSocket dll --> AFP2PDF dll
Existing application in deployed in Windows Server 2003 (32 – bit System) and the stiSocket dll is built for 32 bit and AFP2PDF dll is also built for 32 bit. So there is no problem in the existing application.
Now we are deploying the code in Windows Server 2008 (64 – bit system) and the first problem we faced is the communication between the >net application and the stiSocket.dll. This issue occurs because the 64-bit application tries to call the 32 bit stiSocket.dll. we solved this issue by re-compiling the stiSocket application in a 64 bit system and we changed the setting of the project to work the dll in 64 bit system.
(we had the source code of the stiSocket application).
Then the problem comes when the stiSocket.dll communicates with the AFP2PDF dll. This again occurs when the 64 bit stiSocket dll communicates with the 32 bit version of AFP2PDF dll. We could not able to change the settings for this dll as we don’t have the source code for this dll.
Is there any way to call the 32 bit C++ dll in the 64 version of dll?
Kindly give your comments on this issue.
Thanks
|
|
|
|
|
Would the application run if it was compiled to 32 bit?
|
|
|
|
|
we converted the .Net application to work for 64 bit machine. The Problem is with communicating the stiSocket dll to the AFP2pDF dll.
|
|
|
|
|
Well, if you don't have the source for the AFP2PFD.dll and there isn't a 64-bit availble, you have two options.
1) Recompile everything back down to 32-bit because you cannot mix 32- and 64-bit code in the same process.
2) Leave your app as AnyCPU and rework the StiSocket.dll code to load the AFP2PDF.dll in a serperate Process, and write a wrapper around the functionality of the .DLL that will marshal remote calls from your StiSocket.DLL to to the exposed functioanlity of the .DLL.
Frankly, I'd go with number 1.
Unless you've got some 64-bit reason that you absolutely need 64-bit support in your app, your 32-bit-only app will work just fine on a 64-bit machine.
|
|
|
|
|
|
Hello to all,
i finally decided to hide or remove the "Dial.." button from ContextMenuContactItem and add the new button that when i click on my own item button show the telephone numbers that contact righ-clicked and selected. How can i make it? Is there some code but NOT ADDIN EXPRESS (we must pay to use it) or solution to take example how to build it?
Is there someone expert and can help me to build it. I have last one week! And also if i click one of number the event click send the number selected in string format to my own function.
Thanks very much for any help.
Thanks!
I will here every hours!! Thanks!
|
|
|
|
|
When creating big applications(even medium apps) there are so many different kinds of exceptions that can come?
How to go about handling them?
And how do prioritize these exceptions?
(We just cannot write a 100 try-catches,can we?)
|
|
|
|
|
You should never be trying to handle exceptions from the whole application in the same place (apart from a last ditch catch-all to put up a message and log a bug report).
In any individual operation, there should be only one or two possible exceptions that can be thrown. You should catch and handle them appropriately as close as possible to the site of the operation.
|
|
|
|
|
We divide our whole application into layers , tiers, components etc. for modularity of a functionality. Cant we have a whole layer just to handle exceptions. In that case if we know that an exception is not being handled properly we will know where to go instead of having to browse through the whole code looking for the pertinent error.
|
|
|
|
|
Basically you either handle the exception, you ignore it (maybe with a message), or you log it (or combination). If you are logging, then basically you are centralizing the handling of the exceptions. What do you expect to do if you try to centralize the exception handling. That would be extremely complex. There are a number of frameworks for logging. We use log4net: log4net Tutorial[^]
|
|
|
|
|
Exceptions are part of the layers where they serve the best purpose, not a layer by itself.
|
|
|
|
|
Handle the exceptions you know you can handle as close as possible.
If you have a place no exceptions can be allowed to escape from, catch the root exception type - this will also catch all derived exceptions. But do this catch last, after the exception types you have different handling for.
If all your exception handling does is log an error, you only need to capture the root type.
|
|
|
|
|
You should know the .NET framework well enough to know what exceptions a method throws. For example, opening a file may cause an exception if the file doesn't exist, etc. Why would you have an application level exception handler for that? The method that opens the file should pop up a message box saying the file was not found.
|
|
|
|
|
On Error Resume Next
SMACK ouch, owe that smarts!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Phanindra261 wrote: When creating big applications(even medium apps) there are so many different kinds of exceptions that can come?
How to go about handling them?
Ideally by the following
1. Anticipate expected conditions that can result in errors. These of course vary by the area of the application/enterprise in which they appear.
2. Consider what the application/enterprise should do when those occur. This includes how or even if it should be logged.
3. Implement the code based on 1/2
4. Unit test the code of 3, including the exception generation
5. Besides the above boundary layers should ALWAYS assume that unexpected errors will occur. Those exceptions should be caught and logged once (not every layer.) Each layer must determine what the result is when an unexpected exception occurs and what the layer (or specific parts of the layer) do when an unexpected exception occurs.
As an example...
A database layer should always expect that communication errors will occur. There are various ways of dealing with this (which do not matter for this discussion) but they should still be expected. Even a clustered database solution can experience communication failure. Whether this is logged depends on how it is handled but even if the database layer is returning it as a result failure is should not log a stack trace, but just log it as a single error (db comm error.)
A database layer should not normally expect a SQL syntax error. That is something that should normally only occur during development or QA. So if it occurs one must log it. The database layer can handle this as a failed result.
|
|
|
|
|
I have this small feeling that we have more control on our application when we manually code it instead of using a code generator. Is it true?
If so then how often should we use a code generator and to what extent?
If not so then can someone guide me to a good place where I can learn about writing code generators?!
THANK YOU
SATYMEVAJAYATHE
|
|
|
|
|
I never use one, I write all my own code.
|
|
|
|
|
Even *.designer.cs files? 
No more Mister Nice Guy... >: |
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
