replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - Unknown symbols in GUI app link
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Unknown symbols in GUI app link
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK

PostPosted: Tue Apr 25, 2017 3:50 pm    Post subject: Reply with quote

Dietmar

I think that there are two things that need fixing here.

1) dbos.ins needs changing to

Code:
      C_EXTERNAL DRAW_TEXT@ "__win_draw_text"(INSTRING,REF,REF,REF)


2) __win_draw_text is not exported correctly from clearwin64.dll.

It should have four arguments. The recommended change is to use DRAW_CHARACHERS@ instead.

You could change dbos.ins but I think that DRAW_TEXT@ will still fail because of (2).
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Apr 27, 2017 11:18 am    Post subject: Reply with quote

Yes,

I have substituted DRAW_TEXT@ by DRAW_CHARACTERS@ in my GUI app code and this worked fine Smile

For those who are interested:
in a remark which I made previously in this post I wondered that a small example containing symbol GET_WKEY1@ could be compiled/linked using ftn95/slink64, our big GUI example, however, left symbol GET_WKEY1@ unresolved.
Although meanwhile this problem is solved, I found that you use character " in C_EXTERNAL definitions of file dbos.ins (ftn95 Version 8.10). When I looked at file clearwin.ins of ftn95 Version 7.10 I saw that C_EXTERNAL definitions of file clearwin.ins used character ' instead. What was the reason for this?

Regards
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK

PostPosted: Thu Apr 27, 2017 12:41 pm    Post subject: Reply with quote

There is no reason for this. You can use either single or double quotes.
Perhaps clearwin.ins was written when FTN77 was still in use.
dbos.ins was written within the last few months and double quotes was just a random choice. Hopefully, if there are any FTN77 users still around then they won't be porting to 64 bits.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2403
Location: Yateley, Hants, UK

PostPosted: Thu Apr 27, 2017 3:19 pm    Post subject: Reply with quote

In real life, double quotes allow you to avoid confusion when using the apostrophe for the Saxon Genitive or word contractions without ambiguity.

In programming, being able to use single or double quotes enables use of the other in character strings , but degrees, minutes and seconds are still difficult, as in:

Code:
"�  '"//'  "'
(similar for feet and inches)

Still not simple, especially when reading it years after writing the code.

Using both types of quotes is one of the things a committed Fortran-77 user is most likely to pick up and adopt, along with inline comments.
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2403
Location: Yateley, Hants, UK

PostPosted: Fri May 05, 2017 9:43 am    Post subject: Reply with quote

It depends if it is a character constant or in a format statement.

"'","'" will only work in a format statement, and would have to be "'"//"'" in a character - this would work in a format statement too.

I think that "''" would work anywhere, as it is the first character that must be matched to the end of the string.

The apostrophe is also a key part of the Saxon Genitive.

Can I have this month's award for pedantry please?

Eddie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1899

PostPosted: Fri May 05, 2017 1:27 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:

The apostrophe is also a key part of the Saxon Genitive.

Can I have this month's award for pedantry please?
Eddie

A fitting reward would be a plaque, engraved with Latin text that is unblemished by punctuation, a la https://i.stack.imgur.com/lMmJi.jpg .
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 12, 2018 4:55 pm    Post subject: Reply with quote

There is another unresolved symbol which I found when linking a 64 bit GUI application, namely

Code:

DELETE_POLYGON_DEFINITION@


I wonder how to get rid of this symbol. The code sequence to create/delete the polygon is
Code:

        CALL CREATE_POLYGON@ (...)
         CALL FILL_POLYGON@(...)
          CALL POLYLINE@(...)
                  ........
         CALL DELETE_POLYGON_DEFINITION@(...)

All 4 subroutines are listed in the ClearWin+ documentation Appendix A, Functions ported from DBOS, Graphics, but only the last is marked as undefined by slink64. I know there are alternate routines, however, I wonder, how to set parameter 4 of DRAW_FILLED_POLYGON@ which is the alternate routine to DELETE_POLYGON_DEFINITION@ (which specifies the fill color using the current color mode).

Thanks for any help.

Regards,
Dietmar
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2403
Location: Yateley, Hants, UK

PostPosted: Tue Jun 12, 2018 11:15 pm    Post subject: Reply with quote

Dietmar, the 4th parameter for DRAW_FILLED_POLYGON@ is an integer created with a call to RGB@. I only use Win32, so it's an INTEGER*4. You call RGB@ with 3 parameters: the Red, Green and Blue components, each described with an integer in the range 0...255. RGB mode, with 24-bit colour is the default in Clearwin these days, no longer the 16 colour VGA mode.

You can specify 'ICOL' as in the documentation using say:

ICOL = RGB@ (0, 0, 0) (for black)

or just put it in the subroutine call, as in:

CALL DRAW_FILLED_POLYGON@ (IX, IY, N, RGB@(127, 127, 127) ) (grey)

You really need to update your codes to use the 'post-DBOS' graphics to future proof them.

Eddie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK

PostPosted: Wed Jun 13, 2018 6:48 am    Post subject: Reply with quote

Dietmar

CREATE_POLYGON@, FILL_POLYGON@ and DELETE_POLYGON_DEFINITION@ belong to a set of DBOS routines that have not been implemented for 64 bits. The first two will link but will fail at runtime. These can be replaced by the single routine DRAW_FILLED_POLYGON@.

POLYLINE@ is provided (via DBOS.INS) but this just calls DRAW_POLYLINE@ which is therefore more direct.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Jun 14, 2018 11:02 am    Post subject: Reply with quote

Paul, Eddie,

thanks for your help and information.

I was a little bit confused because the only symbol out of CREATE_POLYGON@, FILL_POLYGON@ and DELETE_POLYGON_DEFINITION@ that slink64 complained about was DELETE_POLYGON_DEFINITION@.

I wondered why the alternate routine to DELETE_POLYGON_DEFINITION@ was DRAW_FILLED_POLYGON@ and thought maybe DELETE_POLYGON_DEFINITION@ would have some visual effect on the screen (like repainting the area covered by the polygon with the background or similar). And I wondered who would free the handle which I thought was still valid under 64 bit.

That's why I asked how to set the color (parameter 4) of DRAW_FILLED_POLYGON@, and Eddie answered this question. What I really meant was to which value I should set the color (e.g. the backgroud color etc.).

Later I found the semantic of DELETE_POLYGON_DEFINITION@ in the Library reference FTN77.

It turned out that DELETE_POLYGON_DEFINITION@ does not have any visual effect on the screen. Hence I think I should replace

Code:

          CALL CREATE_POLYGON@ (...)
          CALL FILL_POLYGON@(...)
          CALL POLYLINE@(...)
                  ........
         CALL DELETE_POLYGON_DEFINITION@(...)


by
Code:

      CALL DRAW_FILLED_POLYGON@(...)
      CALL DRAW_POLYLINE@(...)

where in call DRAW_FILLED_POLYGON@ and DRAW_POLYLINE@ the same colors are used as in CALL FILL_POLYGON@ and POLYLINE@, respectively.

This means that routines CREATE_POLYGON@ and DELETE_POLYGON_DEFINITION@ are obsolete in the 64 bit ftn95 compile environment. To my opinion this is a slight difference to the information given in the table of alternate routines in the ClearWin+ documentation.

Paul, could you please confirm, if my idea of code replacing mentioned above is correct?

Thanks and regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK

PostPosted: Thu Jun 14, 2018 11:24 am    Post subject: Reply with quote

Dietmar

Yes I can confirm that you are correct.

CREATE_POLYGON@ and FILL_POLYGON@ are not implemented for 64 bits. When called they produce a runtime error report. So your tests must have avoided calls to these routines.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Fri May 29, 2020 3:09 pm    Post subject: Reply with quote

Paul,

I am currently trying to link an INTEL64 app with clearwin64.lib/clearwin64.dll from ftn95 version 8.62.1 (internal version numer 22.3.15).
The code named mymove.for is
Code:

      character*256 mybuffer_src,mybuffer_target,c,curdir$
      integer*2 n
      N=5
      mybuffer_src='abcdfghijk'
#IF SALFORD
      call  MOVE@(mybuffer_src, mybuffer_target, n)
#ELSE
      call  MOVE$(mybuffer_src, mybuffer_target, n)
      c=curdir$()
      write(*,*) 'Current Directory: ', c
#ENDIF
      write(*,*) 'mybuffer_src=',mybuffer_src(1:n)
      write(*,*) 'mybuffer_target=',mybuffer_target(1:n)
      read(*,*)  c
      end

I tried to compile it via command
Code:

ifort mymove.for /Zi /debug /fpp /DINTEL64 clearwin64.lib

, however, symbol MOVE$ remained unresolved, the corresponding error message was
Code:

mymove.obj : error LNK2001: unresolved external symbol MOVE$
mymove.exe : fatal error LNK1120: 1 unresolved externals

. The same code compiles successfully for SALFORD via command
Code:

ftn95 mymove.for /debug /link /64 /CFPP /DEFINE SALFORD 1

. Moreover if commenting/deactivating the call of MOVE$ for INTEL64 the compile is successful. Now I wonder if symbol MOVE$ might have been forgotten somewhere in the environment needed when building INTEL64 stuff making use of clearwin64.

Regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK

PostPosted: Fri May 29, 2020 4:27 pm    Post subject: Reply with quote

Dietmar

MOVE@ is an inline FTN95 routine. It is translated directly into assembler code.

I guess that I could add it to clearwin64.dll and maybe even use the same name.

Note that FTN95 usually allows the $ as an alternative to @ so generally you don't need conditional compilation blocks like that used here.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 02, 2020 11:34 am    Post subject: Reply with quote

Paul,

it would be nice if I could use MOVE$ from clearwin64.dll, for my current INTEL64 implementation uses INTEL C functionality to implement it. Would it be possible to treat other routines (e.g. LS,RS) in the same way?

Concerning your note I am confused: if I substitute MOVE$ by MOVE@ in line 8, then the ifort command mentioned in my post results in
Code:

mymove.for(8): error #5078: Unrecognized token '@' skipped
      call  MOVE@(mybuffer_src, mybuffer_target, n)
----------------^
compilation aborted for mymove.for (code 1)

. This is in sync with your document doc\clearwin64.txt (Using 64 bit ClearWin+ with third party compilers) where you stated
Quote:

First, ClearWin+ routines that end with the @ symbol must be changed so that they end with the $ (dollar) symbol.

Compiling mymove.for with ftn95 via command
Code:

ftn95 mymove.for /CFPP /debug /link

results in
Code:

WARNING the following symbols are missing:
MOVE$                                    c:\ds\samples\salford_8.62\lgotemp@.obj

and executing mymove.exe results in a runtime error (call to missing routine _MOVE$).
Regards
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8217
Location: Salford, UK

PostPosted: Tue Jun 02, 2020 12:18 pm    Post subject: Reply with quote

Dietmar

MOVE$ will not work at the moment but routines like WINIO@ can be written as WINIO$ and this form should work for both FTN95 and INTEL.

I will aim to provide MOVE$ and at least some of the other FTN95 intrinsics.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group