Re: interfaces and GUIDS - C# Discussion Boards

17-Dec-03 3:29

If the inputs are validating, crashing the problem makes sense?! WTF | :WTF:

You need to validate your inputs and gracefully warn the user or exit, depending on the circumstances (exiting, like in the case of 3 invalid password attempts or something). Crashing your program is not acceptable for clients!

Besides, never trust user input. Always validate input, even if it's just checking to see if input was provided. You should also put such commands in try-catch blocks so execeptions are caught and handled correctly.

One more thing, when using modal dialogs, you need to dispose them when you're done. So, after you get done grabbing values form your cust variable, call cust.Dispose(). Otherwise, the memory for the modal dialog (actually, this has to do with native handles used to display the modal dialog) won't be freed. This also helps keeps the memory footprint of your app down.

As far as MDI tutorials, I can't recommend any, but you should read the .NET SDK Documentation for the MDI-related methods and properties, such as Form.MdiChildren, Form.MdiParent, Menu.MergeMenu, and the like. It's not great, but it might give you a little more insight to some specific questions you might have. Otherwise, just ask the forum! Smile | :)

-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----

Re: Mdi problemo

Heath Stewart17-Dec-03 3:32

17-Dec-03 3:32

Oh, and as far as validating inputs, it's common practice to not let the user close the dialog until they've either canceled the dialog or enter the valid values. You should also get a DialogResult back from the ShowDialog call so you know what the user did:

DialogResult result = cust.ShowDialog();
if (result != DialogResult.OK) return;

Or something like that. Then, in your form, make sure your OK and Cancel buttons have the right DialogResult property set (OK or Cancel), and that your form specifies the Form.AcceptButton and Form.CancelButton.

Re: Mdi problemo

datainjector17-Dec-03 10:15

datainjector

17-Dec-03 10:15

Thanks alot for the help Smile | :)

Remote Debugging

mikemilano16-Dec-03 9:13

mikemilano

16-Dec-03 9:13

i need to develop on a network server here at work, but we can't get it setup right.

according to microsoft, you either need to be logged into the network as the same user as the asp.net process runs under, ... or ... logged in as an administrator of the box.

our admin says he can't set me up as admin, and i can not login as the asp.net process.

I am setup in the 'Debug' group on the server, but I still get permission errors.

anyone know any other way i can debug remotely with asp.net ?

Re: Remote Debugging

Heath Stewart17-Dec-03 3:23

context menu with drag/drop and right click

17-Dec-03 3:23

It doesn't really matter which group you're in, so long as you have the debugging privilege (and just because there is a group named 'Debug', it doesn't necessarily mean these privileges have been granted). The priviliges should be configured in the Security snap-in for the computer, DC, or domain. The admin should also make sure that the Local Security Policy for the computer has the privileges assigned. Since domain privileges take precedence over local ones, using the Local Security Policy shows you whether a user or group really will have those privileges.

Second, don't forget to enable debugging in the Web.config file.

Finally, make sure the debugging tools are actually installed on the server. If you install the .NET Framework SDK on the server, I believe this is enough. In the VS.NET setup, there are some additional tools you can install remotely, but I believe these are only for DCOM debugging.

mikelb16-Dec-03 4:37

mikelb

16-Dec-03 4:37

I'm looking for menu code that will allow the user to drag/drop menu items to move them where they want and allow detection of a right click on a menu item.

Any pointers would be appreciated.

interfaces and GUIDS

Jinwah16-Dec-03 4:27

Jinwah

16-Dec-03 4:27

Can anyone help?

I want to code an interface and assign a GUID to it.

public interface IMyInterface
{
}

On the web I found articles that say I should put the interfaces GUID above the interface declaration. But I get an error message saying GUID is not recognised. My using clause has System. So how can I do this?

The reason is in Delphi my objects support interfaces and then by zooming thru a list of objects I can ask if the object supports the interface and if so talk to the object thru that interface.

I have had a good look thru my books and internet articles but cannot find any really good info.

If there is a new way to do this I would also be interested.

Thanks

Luke

Heath Stewart16-Dec-03 5:11

16-Dec-03 5:11

Yes, you do use the GuidAttribute but you must use the right namespace: System.Runtime.InteropServices. You can either include it toward the top with the using statement, or prefix your GuidAttribute (or any class for that matter) with the proper namespace. You must also be referencing the assembly in which the Type contains. I'm only mentioning this so you understand. The System.Runtime.InteropServices.GuidAttribute Type is in the mscorlib.dll assembly, so it is automatically referenced by the compiler (unless it's told otherwise, which is only possible with the command-line compiler).

Jinwah16-Dec-03 5:34

Jinwah

16-Dec-03 5:34

is that above the interface declaration

System.Runtime.InteropServices.GuidAttribute["....."]
public interface IMyinterface
{
}

And how can I ask an object if it supports the interface so that I can talk to it soley thru that interface (this is how I would have done it in Delphi)

Cheers

Luke

Heath Stewart16-Dec-03 5:45

16-Dec-03 5:45

No offense meant, but you should probably read the C# specification. Attributes are like so (fully-qualified example):

[System.Runtime.InteropServices.Guid("363EBCCC-5E9A-4e14-8A5D-F0DA44E69EF9")]
public interface IMyInterface
{
{

In C# (and some other languages, but you have to read their specs to find out), you can drop the "Attribute" at the end of attributes. If you want to use properties that aren't in the constructor parameters, fill all the necessary params then use PropertyName=Value, like so:

[MadeUpAttribute("somestring", SomeParam="SomeValue")]
public class SomeClass
{
}

Jinwah16-Dec-03 22:04

Jinwah

16-Dec-03 22:04

No offence taken. I have brought 2 very good reference texts for C# / .NET. My problem is that I professionally program in Delphi. So I know what I want to do but I haven't yet got used to framing the question I want to ask in C# terms to get the answer. But moving to C# has been very easy due to the similar class libraries so I have a head start on my fellow C++ m8s.

Thanks for your help tho.

Heath Stewart17-Dec-03 3:13

17-Dec-03 3:13

My comment wasn't in reference to how you "framed" your question, but rather your syntax. Attributes in C# are enclused in square brackets ([ and ]) and you tried using them for your constructor params, which are always parens (( and )). This is just a simple matter of syntax. While it's true that the syntax (i.e., language) you use to write your code for .NET isn't really so important (knowing how to use and extend the base class library, and how to make your own libraries and applications is more important), you still need to know the syntax of the language you've choosen. I was just pointing out that you should read over the C# language specifications to know exactly what the syntax is - you might even learn a few tricks that aren't always discussed in books (like using the using statement to automatically dispose IDisposable implementations, or to use the same statement to creat a Type alias (especially handy when you have Type collisions, i.e. two different Types with the same name that belong to two or more namespaces you've imported).

Setting Up Computer to run IIS/ASP.NETwith C#

Member 26118817-Dec-03 6:02

Member 261188

17-Dec-03 6:02

Im my opinion, a good example of the uses of attributes is when it comes to describing properties for the property explorer in Visual Studio.net.

using System;
using System.ComponentModel;

namespace Examples
{
    public class ExampleControl : UserControl
    {
        private IndentStyle m_eExampleProperty = IndentStyle.Smart;
        [
        Category("Design"),
        Description("Gets/sets an example value."),
        DefaultValue(IndentStyle.Smart),
        Browsable(true)
        ]
        public IndentStyle ExampleProperty
        {
            get
            {
                return m_eExampleProperty;
            }
            set
            {
                m_eExampleProperty = value;
            }
        }
    }
}

This would produce this kind of output:

If you want to try this out, just cut-and-paste the code into a source file, and create an instance of the control on the designer form.

- Daniël Pelsmaeker

Microsoft is to quality software what McDonalds is to gourmet cooking

Larry J. Siddens16-Dec-03 4:22

Larry J. Siddens

16-Dec-03 4:22

I need some help getting my puter setup to run ASP.NET apps. I have IIS installed and the Web Publishing is running. I have also shared the folder where the app is. I keep getting an error:

"http://localhost/<name> HTTP 500 internal error!

Real informative! Can anyone give me some suggestions on what needs to be running?

Thanks

Larry J. Siddens

Heath Stewart16-Dec-03 5:08

16-Dec-03 5:08

Well, for one, you need to install ASP.NET with the .NET Framework. If you're having problems, you should run "aspnet_regiis.exe /i". Read more about aspnet_regiis.exe in the .NET Framework SDK documentation. There's some other options.

Another possibility is that your ASP.NET page - or your IIS extension mappings - have an error and are causing a server error. Without knowing more, it's hard to say. The error says it all: server error. Millions of things could be wrong.

Larry J. Siddens16-Dec-03 7:03

Larry J. Siddens

16-Dec-03 7:03

Hey, new message!

Unable to open Web project "project name". The file path <path> does not correspond to URL 'http://Localhost:/<project name>'. the two need to map to the same server location. HTTP Error 403: Access.

I get this when I open a project under C#!

Larry J. Siddens

Heath Stewart16-Dec-03 11:06

16-Dec-03 11:06

HTTP error code 403 is access denied. Check your filesystem permissions and make sure that the account under which ASP.NET runs (by default, a local user named ASPNET) has permissions to at least read and list the files and directories. Also make sure that your account has read/write permissions.

Second, you must already have a project in the web application (in this case, the root application on 'localhost'). If you do, you might try typing the name in, like 'http://localhost/project.csproj'. Sometimes VS.NET doesn't show directories correctly, but I've really only experience this with remote servers on a different network (like opening up a project at work from home).

Finally, the project in 'http://localhost' has to have that host in the project file itself. The project file is just an XML file so browse to the directory in which your project is located (for example, 'C:\Inetpub\wwwroot'), open it up in notepad or some other vanilla text editor, and change the host to match the location in which you're trying to open it.

problem with a shared assembly in a VS solution

Not Active17-Dec-03 3:22

Not Active

17-Dec-03 3:22

I've run into this several times before. The most likely this what you need to do.

http://www.codeproject.com/script/comments/forums.asp?forumid=12076#xx693463xx[^]

Tim Kohler16-Dec-03 3:19

Tim Kohler

16-Dec-03 3:19

I'm having a problem with shared assemblies > 2^16 bytes in size.

My assembly is in a solution along with a console app that references the
assembly. The app is set up to reference the assembly (the reference path
is pointed to the assemblies output directory). When I do a build, the
assembly is failing to build because the .dll is loaded. If I remove the console app's
reference to the assembly everything is fine.

I'm getting the following output from the build:
The file 'Test_Library.dll' cannot be copied to the run directory. The
process cannot access the file because it is being used by another process.

Could not copy temporary files to the output directory.

I've created a few other shared assemblies with no problems. This is the
first time I've seen this exact problem and in trying to run it down I've
discovered that if the .dll's size is < 65536 bytes (as all my other ones
are), this doesn't happen. It looks like VS is loading the .dll when I add
the reference for the console app. If I delete the console app's reference
to the assembly, I am able to build the library.

I hope one of you has run across this before.

thanks for any help

Re: problem with a shared assembly in a VS solution

Heath Stewart16-Dec-03 3:45

Re: problem with a shared assembly in a VS solution

16-Dec-03 3:45

Yes, and it's definitely a bug in VS.NET. One thing that helps eliminate the problem is to use a Project reference instead of a file reference. When adding the reference to a project in your solution to another project, click on the Projects tab in your Add Reference dialog. Select the project. This not only helps eliminate the problem a little, but it also ensures that whenever you make a build of your library/application, that the proper build of the dependency is created as well. For instance, when you create a Debug build all dependencies are built in debug mode.

When this problem occurs, pretty much all you can do is make sure that your application isn't running (use the Process tab in the Task Manager to really make sure - just because you can't see it doesn't mean it's not running) and restart VS.NET to get it to release the lock on the executable(s).

Tim Kohler16-Dec-03 4:04

Tim Kohler

16-Dec-03 4:04

Alright, thanks for the feedback. I'll try a project reference. This is a real bummer though.. <sigh>

I hope they fix this soon as it really stinks up developing a library of any size.

Re: problem with a shared assembly in a VS solution

Heath Stewart16-Dec-03 4:07

Drag Drop - Simple Theory - Simple Solution?

16-Dec-03 4:07

It doesn't have anything to do with the size of the assembly. You've found a pattern, but a pattern unique to you. That happens to us with assemblies of all sizes, and assemblies that are referenced by others both frequently and infrequently.

This problem exists in both VS.NET 2002 and 2003. While I too hope they fix it, it's not looking too good. I know a lot of people - including myself - have posted this bug to their newsgroups, but you should as well (use the NNTP server msnews.microsoft.com or the web-based news reader on their site in various places). Every mention should help.

Tristan Rhodes16-Dec-03 2:58

Tristan Rhodes

16-Dec-03 2:58

Would it be possible to combine the FileFormat.FileDrop with an automatic file construction?

For instance, when the mouse button is pressed, and dragdrop is intiated, when the mouse pointer leaves the managed enviroment, the program constructs the dragged item in the root / temp directory, and forwards the file name (With path) to the arguments used by the dragdrop, thereby, the file is created in the temp directory, and then moved.

This would negate the need to worry about interfacing with COM, and simplify the whole process.
The only things I am uncertain about are:

1) How to determine when the mouse has left the managed enviroment. (X,Y mouse coorinates mapped to the form size? This could be process intensive, so i'm not sure).

2) Deleting a file. Can it be done without security settings, or is that irrelivent?

3) Would it be worth constructing the file to begin with anyway? It could disrupt the drag drop if the file is large or there are many of them. Is there any way to manage a file constructing without chewing up 100% of the CPU? (Thread perhaps?)

4) What about multiple files? Can the drag drop method handle multiple objects? Construct 5-6 objects by stream, and then enable the drag and drop?

There are a number of problems I can see with this method, but there must be some way to manage it. If the file is being written to or is still open when the drop command is sent, then it won't work for one.

I'm just toying with ideas here.

Any thoughts?

Cata

Re: Drag Drop - Simple Theory - Simple Solution?

Tristan Rhodes16-Dec-03 3:05

Tristan Rhodes

16-Dec-03 3:05

Unless, I don't perform the dragdrop operation immediately, and when the file is completed, I could then pull the file path from the COM method, and move the file using that?

Re: Drag Drop - Simple Theory - Simple Solution?

Heath Stewart16-Dec-03 3:42