%DD stability issue

HI I have just noticed that any of my application that use %dd now hang/crash when the %dd spin controls are used.

My current salflibc.dll 7.2.7.8

i don't know it if relevant but i also tend to use %il in conjunction with %dd

when i try the same application using an older salflibc.dll (25.11.3.7) the %dd control work without issue

I tried the latest versions 9.14 (32bit) but the debugger was too unstable, not selecting the correct lines of code for breakpoint, going to the wrong line when 'go to origin' etc.

regards

steve

Steve

There has been a recent fix for %dd but it was in relation to %rf.

Can you send/post a sample program that illustrates the failure?

HI Paul

the following example demonstrates this issue. when the OK button is pressed the variable ITEM is zero thanks

steve

  program test
  
   include <windows.ins>
		integer test_CB
		external test_cb
		integer item,iwin
		common /test_1/item
		item = 1
		
     IWIN = WINIO@('%dd%3^rd&amp;',1, item, test_CB)
     IWIN = WINIO@('%ff%bt[OK]')

		write(*,*) ' item final = ',item
	   
	   end
	   
	   integer function test_cb()
	    common /test_1/item
	   test_cb = 1
	   
	   write(*,*) ' item = ',item
	    
	    end

Steve

Your program works fine for me.

Have you tried using the latest downloads?

See https://forums.silverfrost.com/Forum/Topic/3780.

HI Paul

The test example and my other built application seem to work as expected with the latest salflibc.Dll (27.8.22.8)

I tried updating my current version (9.10) to 9.14 using the updated ftn95 & dlls but i found that the debugger (wsdbg.exe) become unstable. There seems to be a mis-match between the actual lines of source code and the imbedded information in the compiled code

I will assume that using the latest dll with older .EXEs will not cause other issues

As a side issue would it be possible to add a 'fixed_size' option to %sy to prevent 3d style dialogues being resized

Thanks for your rapid response

steve

Steve

Off hand, I don't know what causes the resizing.

I would need a sample program in order to investigate and then provide a option if this is feasible.

I couldn't reproduce the resize effect in a simple example.

After wading through the larger applications, buried in a shared library I found a call to SET_OLD_RESIZE_MECHANISM@() which seems to be the culprit. Some of my code goes back to the early days of Clearwin so i should find some time investigate what legacy functions need to be deleted

thanks

steve