Page 1 of 1

ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 15 Aug 2018 13:00
by Harrison Pratt
The code below compiles happily in 32bit mode but gives an e504 error in 64 bit mode:

e504 The expression has type '::integer', which is incompatible with the type 'listViewControl::itemID'

How can I work around this error for 64bit compilation?

Code: Select all

class predicates     sssToItemList : (string_list_list, positive StartingIndex) -> listViewControl::item_list.     % Convert a string_list_list to an item_list incrementing from Starting Index. clauses     sssToItemList(SSS, StartingIndex) = ItemList :-         CurrX = varM::new(StartingIndex),         ItemList =             [ Item ||                 SS in SSS,                 ItemID = uncheckedConvert(listViewControl::itemID, CurrX:value), % <== e504 error here on 64bit compilation                 Item = ssToItem(SS, ItemID),                 CurrX:value := CurrX:value + 1             ].   class predicates     ssToItem : (string_list, itemId Index) -> listViewControl::item determ. clauses     ssToItem([H | TT], Index) = Item :-         Item = listViewControl::item(Index, H, -1, [], TT).

Re: ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 16 Aug 2018 11:28
by Paul Cerkez
not too sure, but have you tried making it convert to an 'int32' ?

Re: ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 16 Aug 2018 12:34
by Gukalov
I would try withou varM...

Code: Select all

clauses     sssToItemList(SSS, StartingIndex) = ItemList :- %        CurrX = varM::new(StartingIndex),         ItemList =             [ Item ||                 list::memberIndex_nd(SS, Index, SSS),                 ItemID = uncheckedConvert(listViewControl::itemID, Index + StartingIndex /*+0*/), % <== e504 error here on 64bit compilation                 Item = ssToItem(SS, ItemID) %                CurrX:value := CurrX:value + 1             ].

Re: ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 16 Aug 2018 12:39
by Harrison Pratt
No such animal as int32! There are, of course, integer8, integer 16 and integer64.

Re: ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 16 Aug 2018 15:35
by Harrison Pratt
I think the problem relates to differences in Windows LPARAM in 32 and 64 bit code.

https://social.msdn.microsoft.com/Forum ... vclanguage

listviewcontrol::itemID is an lparm domain in VP and I wonder if the conversion of various flavors of integer are not implemented in the VP8 compiler.

When I try various integral domains in uncheckedConvert/2 I get the same error and removing use of varM is also unhelpful.

Thanks for your suggestions. I hadn't thought of trying those.

It remains a puzzle! :?

Re: ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 16 Aug 2018 17:04
by Paul Cerkez
Sorry, I've doing so much programming in c# lately I got confused. :oops:

my intent was correct though: 32 vs 64 natives.

Re: ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 16 Aug 2018 20:00
by Thomas Linder Puls
wParam, lParam and lResult are used in Windows message handling, sometimes they contain a number, sometimes a pointer to something. To be able to hold a pointer they have pointer size, so on 64bit they are 64bit wide.

When they represent numbers a wParam is represented as a unsigned number whereas lParam and lResult are represented as signed numbers. This means that it is a bit "tricky" to convert from a 32 bit number to a 64 bit version of these domains.

To make sure that it is done correctly, you should use the predicates mkW, mkL and mkR in gui_api.

In this particular case you can do like this:

Code: Select all

                ItemID = convert(listViewControl::itemID, gui_api::mkL(CurrX:value)),

Re: ListviewControl compilation 32bit vs 64 bit, VP8

Posted: 16 Aug 2018 20:48
by Harrison Pratt
Thank you, Thomas!

Your explanation gives me the "hooks" I need to understand this in more depth -- of course, your suggested code modification works in 32 & 64 bit, too.

Are mkW, mkL and mkR strictly VP constructs or are there equivalents in the .NET world, too?

I see now that this is documented in the Wiki, but it would have been hard for me to stumble upon it:

https://wiki.visual-prolog.com/index.ph ... rade_Notes

I really do miss printed documentation, but most of that is gone forever and not only from VP.