C# Discussion Boards - CodeProject

Windows Tab Control Flickering

1-Dec-10 3:54

C#[^]

WinForms[^]

Access database design[^]

ADO.Net[^]

Come back when you get stuck

Life goes very fast. Tomorrow, today is already yesterday.

vishnukamath1-Dec-10 1:37

vishnukamath

1-Dec-10 1:37

hi,

i used tab control in windows form , and i added five tab pages in tab control
,and i added 2 datagridview controls in each and every tab page and binding data for all Datagridviews
in From_Load Event .In Form Displayin with Filckering, so how to stop flickering for form loading.Could
you suggest me better way.

Regards,
Vishnu.

Re: Windows Tab Control Flickering

Abhinav S1-Dec-10 1:42

Abhinav S

1-Dec-10 1:42

This[^] thread may help you.

The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.

My latest tip/trick

Visit the Hindi forum here.

Switching on type

creatiive30-Nov-10 23:44

creatiive

30-Nov-10 23:44

Hi,

This is probably a design issue really. I have an object which is AbsMyObject (abstract). Now, what I am currently doing is testing what type it is, and passing it in to a method like this;

if (AbsMyObject is type1)
myMethod((type1)AbsMyObject);
if (AbsMyObject is type2)
myMethod((type2)AbsMyObject);

Im just overloading 'myMethod' so depending on what type my object actually is, a different method is called. Whilst this implementation works as expected, im ending up with tons of these "if object is" If statements and it just feels like a bad design. It also feels like this might have been encountered before and so there might be a better way of achieving this Smile | :)

Any pointers would be greatly appriciated!
Regards,

phil.o1-Dec-10 0:01

phil.o

1-Dec-10 0:01

Hi,

Why not doing your tests inside your method ? This way, you wouldn't have to care about it when you call your method.

For example :

private void myMethod(AbsMyObject myObject)
{
   if (myObject is type1)
   {
      // Do something
   }
   else if (myObject is type2)
   {
      // Do something else
   }
   else
   {
      // Do something here when myObject is none of expected types
   }
}

Pete O'Hanlon1-Dec-10 0:49

Pete O'Hanlon

1-Dec-10 0:49

You're right - it sounds like an absolute design nightmare. If you just want to do something different inside your concrete implementation classes, why not rework it so that you use the same method for each implementation? That way, you completely remove the need to know about the implementation? By doing this, you will create a much more loosely coupled application.

I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Onyx

musefan1-Dec-10 1:01

1-Dec-10 1:01

What do you mean by 'abstract'? that it is an abstract class? Which I believe cannot be instantiated so is AbsMyObject of a type that inherits from an abstract class?

If this is the case the your absract class can identify a common function such as MyMethod. Then each of your inheriting class types can implement this function in its own way.

Then you can call function like so...

((AbstractClass)AbsMyObject).MyMethod();

...maybe I am misunderstanding what you are trying to do, if this is way off then please further explain what you are trying to achieve and what you are working with (class/type wise)

Life goes very fast. Tomorrow, today is already yesterday.

creatiive1-Dec-10 2:34

creatiive

1-Dec-10 2:34

Thank you all for your replies!

This is what I need in this case;

"If this is the case the your absract class can identify a common function such as MyMethod. Then each of your inheriting class types can implement this function in its own way."

I knew something was wrong with it but didn't quite know how to alter it. This works much better and each object can just have its own implementation of the method. My design skills are a bit poor at the moment Smile | :)

Thanks!

musefan1-Dec-10 2:55

1-Dec-10 2:55

No problems also be aware that there an Interface is similar to a abstract class in what it may be used for. I don't know your exact requirements but if you don't know about Interfaces then you might want to check them out.

Here is a comparison between Abstract classes and Interfaces which may identify if you could make use of an Interface instead...

Abstract Class versus Interface[^]

Life goes very fast. Tomorrow, today is already yesterday.

Keith Barrow1-Dec-10 1:18

Keith Barrow

1-Dec-10 1:18

I'm just doing the schoolboy error check, so don't take this amiss, are you sure you haven't really got:

AbsMyObject.MyMethod();

I.E. The method really belongs in the AbsMyObject class rather than the caller?

Also I tried this (to make sure I wasn't about to make a schoolboy error Smile | :)

) and it works without the cast:

public abstract class Foo { }
public class Bar : Foo { }
public class Baz : Foo { }
public class Qux : Baz { }
public class Quux : Foo { }

class Program
{
    static void MyMethod(string id, Foo arg) { Console.WriteLine("{0} Called Object Type {1}", id, arg.GetType()); }
    static void MyMethod(Foo arg) { MyMethod("Foo", arg); }
    static void MyMethod(Bar arg) { MyMethod("Bar", arg); }
    static void MyMethod(Baz arg) { MyMethod("Baz", arg); }

    static void Main(string[] args)
    {
        MyMethod(new Bar());
        MyMethod(new Baz());
        MyMethod(new Qux());
        MyMethod(new Quux());
        Console.ReadLine();
    }
}

Sorry if I misunderstood your problem, but you are right, such if statements have a bad code smell. [Edit]: If those two options don't apply, Pete's suggestion is good. Can MyMethod be refactored to accept the base class and handle the class based differences inside it?

Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-A Dead ringer for Kate Winslett[^]

musefan1-Dec-10 1:24

1-Dec-10 1:24

I think his issue is that he has an object type and therefore doesn't know the actual type of the object and cannot just call the method. For example...

MyMethod(new object());//this would not work but effectively is what he has

Life goes very fast. Tomorrow, today is already yesterday.

Keith Barrow1-Dec-10 1:52

Keith Barrow

1-Dec-10 1:52

I think more complete code from the OP might help. I'm not sure I understand his question in that, I understand the problem that he needs to determine the type for a method call, but I don't know why he doesn't know it in the first place. I read the OP as all the types coming from some abtract base object.

Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-A Dead ringer for Kate Winslett[^]

PIEBALDconsult1-Dec-10 2:26

PIEBALDconsult

1-Dec-10 2:26

musefan wrote:
doesn't know the actual type of the object

The runtime will.

Pete O'Hanlon1-Dec-10 2:57

Pete O'Hanlon

1-Dec-10 2:57

This would argue that he either needs an interface, or he needs to use generics instead. Basically, what he has here is a form of class factory, and there are lots of neat implementations that can be used.

I have CDO, it's OCD with the letters in the right order; just as they ruddy well should be

Forgive your enemies - it messes with their heads

My blog | My articles | MoXAML PowerToys | Onyx

Call XP Mode shortcut programmatically [modified]

PIEBALDconsult1-Dec-10 2:28

PIEBALDconsult

1-Dec-10 2:28

I don't think that's necessary; did you try it without the casting?

But if you do need it, take a look here[^].

spif200130-Nov-10 20:36

spif2001

30-Nov-10 20:36

Hi
I'm trying to call a XP Mode shortcut programmatically, but I keep getting the same error message:

"problem starting C:\windows\system32\VMCPropertyHandler.dll The specified module could not be found"

I tried with the following:

string startPath = @"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup";<br />
Process p = new Process();<br />
p.StartInfo.FileName = startPath + "\\XPModeInitializer (Windows XP Mode).lnk";<br />
p.StartInfo.UseShellExecute = true;<br />
p.Start();

But I have also done many variants. I even tried making a bat file, that just call the link. The bat file itself works when double-clicked, but when called from within my code like the following snippet, I get the same error message:

Process p = new Process();<br />
p.StartInfo.FileName = Environment.CurrentDirectory + "\\CallXPModeInitializer.bat";<br />
p.StartInfo.UseShellExecute = true;<br />
p.Start();

I also tried taking the shortcut parameters and using them myself like this:

string file = System.Environment.SystemDirectory + @"\rundll32.exe";<br />
string arguments = System.Environment.SystemDirectory + @"\VMCPropertyHandler.dll,LaunchVMSal ""Windows XP Mode"" ""||a9c104ed"" ""XPModeInitializer""";<br />
Process p = new Process();<br />
p.StartInfo.FileName = file;<br />
p.StartInfo.Arguments = arguments;<br />
p.StartInfo.UseShellExecute = true;<br />
p.Start();

But it produces the same error message,
I'm confused at to why a direct use of the bat file works, when the call to the bat file from within C# fails!?

How can I call a XP Mode shortcut from within C# code?

I'm in the high-fidelity first class traveling set.
And I think I need a Lear jet.

modified on Wednesday, December 1, 2010 4:35 AM

Rajesh Anuhya30-Nov-10 22:27

Rajesh Anuhya

30-Nov-10 22:27

System.Environment.SystemDirectory

it self return the "c:\windows\system32\"

why are you aging adding the "system32" in your code ...

System.Environment.SystemDirectory + @"\system32\VMCPropertyHandler.dll,LaunchVMSal ""Windows XP Mode"" ""||a9c104ed"" ""XPModeInitializer""";

Rajesh B --> A Simple Programmer <--

spif200130-Nov-10 22:35

spif2001

30-Nov-10 22:35

Bad copy paste. Smile | :)

Fixed...

Fixing the System32 part does not make any difference though. It still fails.

I'm in the high-fidelity first class traveling set.
And I think I need a Lear jet.

Eddy Vluggen1-Dec-10 1:23

Eddy Vluggen

1-Dec-10 1:23

spif2001 wrote:
I'm confused at to why a direct use of the bat file works, when the call to the bat file from within C# fails!?

You could try setting the WorkingDirectory[^];

If the property is not set, the default working directory is %SYSTEMROOT%\system32.

I are Troll Suspicious | :suss:

spif20011-Dec-10 1:52

spif2001

1-Dec-10 1:52

Sorry sorry sorry... stupid me...

I didn't notice my projects in Visual Studio was set to x86. Setting them to Any CPU solved my problems.

I guess when run as x86, the System32 part of the path gets redirected to the SysWOW64 folder. In which of course the desired files are not placed.

I'm in the high-fidelity first class traveling set.
And I think I need a Lear jet.