xsharp.eu • How to solve class related code issues possible in VO but not in .Net? - Page 2
Page 2 of 4

How to solve class related code issues possible in VO but not in .Net?

Posted: Wed May 06, 2020 5:49 pm
by wriedmann
Hi Dick,
why don't use a extension method for this?
This is code from my own class library:

Code: Select all

static class XsharpCompatibility

static method AutoSize( self oListViewColumn as ListViewColumn ) as void
	local nIndex		as int
	local nWidth		as int
	local oOwner 		as ListView

	oOwner			:= oListViewColumn:Owner
	if oOwner != NULL_OBJECT
		nIndex				:= int( oOwner:__GetColumnIndexFromSymbol( oListViewColumn:NameSym ) ) - 1
		ListView_SetColumnWidth( oOwner:handle(), int(nIndex), shortint( _cast, LVSCW_AUTOSIZE ) )
		nWidth				:= ListView_GetColumnWidth( oOwner:Handle(), nIndex )
		ListView_SetColumnWidth( oOwner:handle(), int(nIndex), shortint( _cast, LVSCW_AUTOSIZE_USEHEADER ) )
		if nWidth > ListView_GetColumnWidth( oOwner:Handle(), nIndex )
			ListView_SetColumnWidth( oOwner:handle(), nIndex, shortint( _cast, LVSCW_AUTOSIZE ) )
		endif
	endif

	return

static method GetPixelWidth( self oListViewColumn as ListViewColumn ) as int
	local dwIndex as dword
	local nPixelWidth as int
	local oOwner as ListView

	oOwner			:= oListViewColumn:Owner
	if oOwner != NULL_OBJECT
		dwIndex 		:= oOwner:__GetColumnIndexFromSymbol(oListViewColumn:NameSym) - 1
		nPixelWidth 	:= ListView_GetColumnWidth(oOwner:Handle(), int(_cast, dwIndex))
	else
		nPixelWidth		:= 0
	endif

	return nPixelWidth

static method SetPixelWidth( self oListViewColumn as ListViewColumn, nNewWidth as int ) as void
	local dwIndex as dword
	local oOwner as ListView

	oOwner			:= oListViewColumn:Owner
	if (oOwner != NULL_OBJECT) .and. (oOwner:CurrentView == #ReportView)
		if (nNewWidth > 0)
			dwIndex 		:= oOwner:__GetColumnIndexFromSymbol(oListViewColumn:NameSym) - 1
			ListView_SetColumnWidth(oOwner:Handle(), int(_cast, dwIndex), nNewWidth)
		endif
	endif

	return

end class
Wolfgang

How to solve class related code issues possible in VO but not in .Net?

Posted: Wed May 06, 2020 6:06 pm
by Chris
Hi Dick,

You may be asking the method to return you an object in the form of the type IC2ListViewColumn, but the actual object (column) created is of type ListViewColumn, so this cannot work like that. It's the equivalent of trying to do

CLASS Dog INHERIT Animal
PROPERTY HasSharpTeeth AS LOGIC
...
LOCAL oBeing AS OBJECT
oBeing := Animal()
LOCAL oDog AS Dog
oDog := oBeing

this cannot work, the being has been created as a generic "Animal", you cannot convert this to a "Dog" which has more specific properties. You need to create it as a "Dog" in the first place instead. Of course the opposite would work, creating a "Dog" and then converting it to an "Animal", which is a broader (parent) class.

How to solve class related code issues possible in VO but not in .Net?

Posted: Wed May 06, 2020 6:57 pm
by FFF
ic2 wrote:
Show us the code. You should really know better than feed only some lines here and there....
Better, make a new sample...

How to solve class related code issues possible in VO but not in .Net?

Posted: Wed May 06, 2020 7:01 pm
by ic2
Hello Wolfgang, Chris,

Thanks for your suggestions. But I am not talking about X# code. I am only preparing my VO code in case I would migrate my projects to X# and if I do that (which still won't be anytime soon I expect, sorry) I want the least possible amount of work in X#.

I have reverted the changes here to go back to the windows class which works fine of course in VO.

On the bright site, I've got now only 11 methods which won't work without additional work in X# (like creating extensions methods) , in my 2nd largest library. So that should enable a migration without too much time to spend on changes.

Dick

How to solve class related code issues possible in VO but not in .Net?

Posted: Wed May 06, 2020 8:51 pm
by ic2
Hello Karl,
FFF wrote:
ic2 wrote:
Show us the code. You should really know better than feed only some lines here and there....
Better, make a new sample...
I did show the full code in message #14404 (which is 2 autosize methods). But I rather leave it like it is as it's not a big deal. It works very well in VO but would not in X# and I thought I overlooked something simple like I did with the Tabcontrol. But as it seems not, there's absolutely no reason why I would spend more time on changing this in VO except spending a bit less time on a future X# migration.

Anyhow, thanks again for the suggestions!

Dick

How to solve class related code issues possible in VO but not in .Net?

Posted: Tue Apr 06, 2021 12:24 pm
by HeikoP
Chris,

i have the same problem with __FormDialogWindow:Dispatch() not from Paul Piko but from ClassicNuVo. Maybe this lib ist from Paul.

But have you inserted this code in the SDK? I couldn´t find the answer in this thread...

Heiko

How to solve class related code issues possible in VO but not in .Net?

Posted: Tue Apr 06, 2021 4:08 pm
by Chris
Hi Heiko,

No, not such method is added. Can you please post the exact contents of this method in your code?

How to solve class related code issues possible in VO but not in .Net?

Posted: Tue Apr 06, 2021 5:01 pm
by HeikoP
Hello Chris,

Dick´s Method above in this thread does a little bit more, for ownerdraw and help-button but here is the method i am using:

METHOD dispatch(oEvent) CLASS __FormDialogWindow
//s Method to pass Escape key from surface to parent window
//l This method looks for the Escape key press on the __FormDialogWindow,
//l which is used by DataWindow and DataDialog. It then posts a message
//l to the parent window. The parent can then act on the keypress

IF oEvent:Message==WM_Command
DO CASE
CASE LoWord(oEvent:wParam)==1
// Return Key pressed
RETURN 0
CASE LoWord(oEvent:wParam)==2
SendMessage(SELF:Owner:owner:handle(),WM_Close,0,0)
RETURN 0
ENDCASE
ENDIF
RETURN SUPER:Dispatch(oEvent)

This was just extending the __FormDialogClass to pass the keys (like ESC) up to the Datawindow.
Heiko

How to solve class related code issues possible in VO but not in .Net?

Posted: Tue Apr 06, 2021 5:19 pm
by Chris
Hi Heiko,

Thanks for the code. So as is probably to be expected, different developers have used a different __FormDialogWindow:Dispatch(), so we can't just insert one version. On the other hand, I think we can instead plug in some code in the __FormDialogWindow class that calls a predefined method if it is available, so everybody can use their one version. I am thinking of something like that:

CLASS SDKExtensions
METHOD FormDialogWindow_Dispatch(oWindow, oEvent)
// insert your specific code here
END CLASS

so what __FormDialogWindow:Dispatch() will do is to search for such a method and call it if it exists. And maybe later we can add such stubs in other places in the SDK as well. I will discuss this with Robert, what also do you guys think about this?

How to solve class related code issues possible in VO but not in .Net?

Posted: Tue Apr 06, 2021 5:23 pm
by robert
Heiko, Others,
The recommended way to solve this problem is:
- Create a subclass of __FormDialogWindow (e.g. MyFormDialogWindow)
- Add the method to the subclass
- In the constructor of YOUR subclass of DataWindow, before you call the SUPER constructor add this code
- SELF:symFormDialog := #MyFormDialogWindow
This will tell the __FormFrame class (which is responsible for creating the __FormDialogWindow) to use your class instead of the built-in class


Robert