4.6 vs 4.5

[jassing]

Is there a list of what 4.6 will break, fix, add, change?
Can we expect userlibs to be incompatible?

[ts-soft]

Can we expect userlibs to be incompatible?

Yes, most tailbited userlibs a incompatible. for example the new optional Parameter FindString breaks many libs.

[MachineCode]

Userlibs usually break with every update. I wish it weren't so.

[netmaestro]

Userlibs usually break with every update. I wish it weren't so.

I've always found it slightly odd that the production of a user library isn't a selectable output choice in the compiler options, native to Purebasic and maintained by the team. It's certainly popular enough to warrant such, imho. Maybe someday..

[Michael Vogel]

Userlibs usually break with every update. I wish it weren't so.

You're right, these (tiny) issues are the reason, why I try to ignore all user libs, if possible.

I understand, that a small developer team can't maintain tons of libraries and user defined functions -- but I still hope, that commonly used/needed functions will be implemented into standard libraries somewhen in the future. This may be possible for easy integer functions (like Minimum, Maximum) or even for OS/HW depended things (set user level, get CPU load etc.)

[jassing]

Can we expect userlibs to be incompatible?

Yes, most tailbited userlibs a incompatible. for example the new optional Parameter FindString breaks many libs.

what about purebasic functions? A lot of examples on the forums do not compile because functions changed/removed

[jassing]

these (tiny) issues are the reason, why I try to ignore all user libs, if possible.

I'm learning this -- it's unfortunate that people release userlibs and then abandon them it's one reason I won't even pay for userlibs -- I'll pay for source, but not userlibs...

I understand, that a small developer team can't maintain tons of libraries and user defined functions -- but I still hope, that commonly used/needed functions will be implemented into standard libraries somewhen in the future. This may be possible for easy integer functions (like Minimum, Maximum) or even for OS/HW depended things (set user level, get CPU load etc.)

Other languages seem to handle upgrades a bit more gracefully allowing addons still to work.. I guess the key wiht purebasic is to ignore userlibs and use lib or obj files and link them in...

[MachineCode]

Apparently you can convert a userlib into a DLL, and then that lib will be compatible with future PureBasic versions, as DLLs don't "age". It wasn't explained how to do it, however. Maybe someone here could write a converter? I imagine it just wraps each userlib command with a DLL equivalent?

(Also, maybe a mod could edit this topic's subject?).

[jassing]

It wasn't explained how to do it, however. Maybe someone here could write a converter?

+1 for that...

(Also, maybe a mod could edit this topic's subject?).

to what?

[ricardo]

Yes, its strange that almost every new version of PB is not fully compatible with recent code. Its a very strange strategy. This forum is full of code that now is almost useless.
I don't understand the point.

I know that code can be adapted to new version, but its not always easy to find and understand quickly which is the new name of the function or how is the new syntaxis needed. Takes sometime to get used to new changes... until new version ads more and more and more changes... Really don't understand the point.

[skywalk]

Takes sometime to get used to new changes... until new version ads more and more and more changes... Really don't understand the point.

Progress

[sphinx]

Takes sometime to get used to new changes... until new version ads more and more and more changes... Really don't understand the point.

Progress

Progress does not mean spoiling old 'Things', it should enhance or at least allow you to use it the old way of doing things - OR -have the option to use the new one in future projects without breaking old ones.

I see this a good point for PowerBasic although I use and prefer PureBasic over PowerBasic.

Well, this is only my thoughts and may be I am wrong!

[dige]

For those who use the editable ComboBoxGadget().

The EventType() seems to changed with v4.6
from 5 (?) to 768 (#PB_EventType_Change).

This is very important, for the event handling of keystrokes.

Code: Select all

  Debug "#PB_EventType_LeftClick = " + Str(#PB_EventType_LeftClick)
  Debug "#PB_EventType_RightClick = " + Str(#PB_EventType_RightClick)
  Debug "#PB_EventType_LeftDoubleClick = " + Str(#PB_EventType_LeftDoubleClick)
  Debug "#PB_EventType_RightDoubleClick = " + Str(#PB_EventType_RightDoubleClick)
  Debug "#PB_EventType_Focus = " + Str(#PB_EventType_Focus)
  Debug "#PB_EventType_LostFocus = " + Str(#PB_EventType_LostFocus)
  Debug "#PB_EventType_Change = " + Str(#PB_EventType_Change)
  
  If OpenWindow(0, 0, 0, 270, 180, "ComboBoxGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
    ComboBoxGadget(0, 10, 10, 250, 21, #PB_ComboBox_Editable)
    AddGadgetItem(0, -1, "Type some text here...")
    SetGadgetState(0, 0)
    
    Repeat
      Event = WaitWindowEvent()
      
      If Event = #PB_Event_Gadget
        Select EventGadget()
          Case 0 ; PB_ComboBox_Editable
            Debug EventType()
            ; PB 4.5 EventType() = 5
            ; PB 4.6 EventType() = #PB_EventType_Change 
        EndSelect
      EndIf
    
    Until Event = #PB_Event_CloseWindow
  EndIf
  

[jassing]

I can understand changing a parameter to a function if it adds functionality -- but this sort of change is really atrocious.... what could be the justification for this?

[Rings]

constants for values or types should never be used
with its number.