How to create a Windows forms custom control

[Chris]

Hi Kees,

Why have you created a designer for the control in the first place? Since it's a very regular subclass from TextBox (so it does not contain sub controls etc), why didn't you simply put the code for your control in a regular new empty prg file?

[Fabrice]

Kees,

sorry but I was asking for "more" code, not only the Class definition. Because troubles could come from something else, like Dialect settings, references, ...

Anyway, I would suspect that the Color type is not enough for the designer. I mean, that Color could come from VO, or WinForms, or something else.
I suggest you specify System.Drawing.Color, or use a USING statement at the beginning of file.

FYI, I've copied/pasted your code, added a USING on top, and everything is fine in the Designer : I've built the code, opened the Designer with a Form, placed your control without any trouble... And it runs !

WRT the ressouces, it might be related to your previous version where the ACCESS/ASSIGN weren't typed.

My 2 cents...
But without the full context, it's a bit a shoot in the dark... The Designer is a sensible beast...

HTH,

[Kees Bouw]

Hi Chris,

There is, of course, no designer for the TextBox subclass. There is a designer for the "Windows Forms User Control" because that is a window. The code for the TextBox subclass is in a (separate) .prg file.

Kees.

Hi Kees,

Why have you created a designer for the control in the first place? Since it's a very regular subclass from TextBox (so it does not contain sub controls etc), why didn't you simply put the code for your control in a regular new empty prg file?

[Jamal]

Hi Kees,

Please upload the project and the subclass lib project to help you better.

[Kees Bouw]

Hi Jamal,

Thank you, and Fabrice, for trying to help. I can't upload my entire solution or a project because of the NDA, besides it is way too big. I have now replaced the access's and assigns of the subclassed TextBox with overloading methods and this eliminated the problems.
I had hoped that someone could find out under which circumstances, in general, additional resources are created in the .resx file of a "user control" (which is actually a window) related to the access's and assigns of a subclassed TextBox that is on it. But maybe it is a peculiarity of Visual Studio and not of X#.

Kees.

Hi Kees,

Please upload the project and the subclass lib project to help you better.

[Jamal]

Hi Kees,

It would be hard to tell without a small sample showing the issue; but naturally no one is asking for your NDA project.

I repeat what Fabrice and Chris said, this could also be caused by the app's compiler options.

Anyway, the following is not fully a strongly typed ASSIGN since you are missing the typing to the RETURN value and this may be triggering the compiler error.

Code: Select all

ASSIGN ConfirmIfBlank(lValue AS LOGIC)

Shouldn't it be written as:

Code: Select all

ASSIGN ConfirmIfBlank(lValue AS LOGIC) AS VOID PASCAL

or

Code: Select all

ASSIGN ConfirmIfBlank(lValue AS LOGIC) AS VOID STRICT

I know you replaced the ACCESS/ASSIGN with methods, but it would be good to know if you can create a small sample.

[Kees Bouw]

Hi,

Another issue with subclassed Winforms controls. I have created a subclass of a DataGridView control. In the constructor of that subclass a method is called that belongs to a global variable, like “MyGlobal:DoSomething()”. On that line Visual Studio crashes (it disappears without any error) when the control is added to the form in the form designer. I could re-create the problem in a sample app that I have attached. In the sample app Visual Studio does not crash but shows an error message saying that the component could not be created because of “Object reference not set to an instance of an object”. The sample app builds without errors or warnings and works fine. It is just that you can’t add the control to a window. If that line is commented out and another build is done it can be added. Am I doing something wrong or is this a bug somewhere?





Kees.

[robert]

Kees,
The problem with this code is that the Windows Forms designer tries to create the control when it opens.
This allows it to show properties that were changed, such as color and size.
In the form designer the Start() function is not called, so your code

Code: Select all

MyGlobal := MyClass{} 

is never executed.

That is why the code

Code: Select all

MyGlobal:DoSomething()

fails, because MyGlobal has not been initialized.
If you had coded the global declaration like this:

Code: Select all

GLOBAL MyGlobal := MyClass{} as MyClass

then the class initializer of the Functions class (where the globals are stored) would have been automatically called by the Form designer which would take care of the initialization of the global.
Another approach is to change the constructor and add a null check

Code: Select all

IF MyGlobal != NULL_OBJECT
   MyGlobal:DoSomething()
ENDIF

Robert

[Kees Bouw]

Robert,

Thank you very much for explaining!

Kees.