Wishlist for PureBasic v4.0

[Psychophanta]

I wish this:

Code: Select all

IncludeLib "file"
IncludeResource "file"
IncludeResourceSkript "file"

3 different commands to include a file ???
You already have: IncludeFile and XIncludeFile. In my opinion, more than enough.

[ts-soft]

Code: Select all

IncludeLib "test.obj"
IncludeResource "version.res"
IncludeResourceSkript "resourcen.rc"

so better

[Killswitch]

IncludeFolder
XIncludeFolder

[Polo]

IncludeFolder
XIncludeFolder

IncludePath is not enough ?

[Killswitch]

Nope, Include path only sets the default path for all files to be included from. IncludeFolder and XIncludeFolder should include all of the .pb files within a folder.

[va!n]

va!n, what's the difference in having .lib, .plib, .yadayada?

You're saying the main problem was that people don't release their sources
and if they stop maintaining it, the users are stuck. How should another
library format change that? Did I miss your point?

@traumatic:
Ok, maybe i explained it a bit bad!? I will try to explain the difference! But first i have to correct you, i dindt sayed that the mainproblme is that people dont releaes their sources and may stop maintaining things! Its still ok, when the author dont release the source! Its another point i mean!

PureBasic has its own lib format. This libs are pre-compiled asm/c/purebasic+talibite routines, also so called obj files stored in a special format (libs) for the PureBasic compiler/linker, right?

When people coding/building a bug in their lib code and dont release their sources - sure we cant fix that kind of bug! But as i said before this isnt the problem i want talk about!

Whats with all the PureBasic libs created using PureBasic and Talibite!? Even when the source(s) are clean and their isnt any bug inside - but what happens, when compiling/creating an officiel lib and the compiler version you are using has somewhere "inside" a small bug!? Sure, this compiler bug will be fixed for the PureBasic release!

When the author stopped his lib project in the meantime, their is still the old lib available (possible with an "old" internaly compiling bug) !!! This is the point we should think about! (as i said in my posting before, i dont want fight here any persons nor programs!)

Another problem could be, when PureBasic will change his lib format in the future, like in the past - so this old compiled lib is no longer useable and your projects - using this lib(s) - may die!

The next point is, when the Author of the lib created/compiled his lib with PureBasic 3.94 (no optimisations by the compiler) but future releases like PureBasic 4.0 may optimize your lib-source in speed as best as possible...! So you may have a very great PureBasic compiler but you must use an old "not optimized" purebasic lib! (because the lib is compiled and it will only linked to your exe)

Such problems can be easy solved for the future! Even when the author has not released the source of his lib!

The official PureBasic libs may have its old lib format as before, because this libs are coded in asm or c - So Fred can easy fix something when a their is a known bug problem!

But for libs created by PureBasic with Talibite, it would be nice, when the libs are no longer pre-compiled as it is for now! (reasons see above)!!

So my idea was, to have a new feature in PureBasic... for example to create PureBasic libs to the standard "dynamic linked libs" format used in c/c++ !!! So everybody can create free libs without spreading his source!
So it should be possible to use this libs again in purebasic by something like IncludeLib (official c/c++ lib format!) !!!

Another way could be, Libs created using Purebasic with Talibite, will saved to a new PureBasic lib format with the extension *.plb or *.plib !!
Ofcourse this libs can be used in PureBasic by something like "IncludePLib" !?

Where is the difference to this plib format? The source of this lib will not be compiled to any machinecode - it will be stored in any crytped or special format - so the source is still unreadable for other persons! The feature of this would be, when using this lib in future projects, newer PureBasic compilers will see that its a plib and will internally compile the lib code new (with future optimisations) and link then to the exe!

I know, i am not good in explaining... ;-/ Btw, if you dont understand what i mean, just drop me a PM and we can talk in german or chat by ICQ

@Blade!
Exactly!

@ts-soft:
Sure, when their is a way to create *.lib or *.blib , their must be a way to include them again... What about following new commands..

IncludeLib "file.lib" <- (official lib format like For c/c++)
IncludeObj "file.obj" <- (official obj format like asm And For c/c++ !?)
IncludeResource "file.res" <- (official resource format)
IncludeScript "file.rc" <- (script, thanks to ts-soft

When Fred like go the way To use his own lib format For libs created by purebasic, also
the so called *.plib format, we need something lile:

IncludePLib "file.plib"

I still hope and wish that some people may understand my idea and maybe you can help me to explain it to other persons too! Thanks

[ts-soft]

@va!n
*.res is compiled Resource (link to exe)
*.rc is ResourceSkript (compile with porc and link)

[va!n]

@ts-soft:
ohhhh.. ok, thanks!

[traumatic]

va!n, so you want to be able to create libraries directly with purebasic w/o
any 3rd party tools. Ok, I think I got your point now. Thanks for explaining.

Regarding the linking of COFF objects, see here:
viewtopic.php?p=90334#90334

[va!n]

The PureBasic IDE 3.94 has an inbuild Structure/Interfaces/Constant Viewer! Would be nice to have all PureBasic structures in this list too! (maybe an own tab section!?

Code: Select all

Structure DrawingInfoStruct
 Type.l    ; Type of the DC
 Window.l  ; Window associated to the DC (if any)
 DC.l      ; DC
 ReleaseProcedure.l ; Address to a procedure to release the DC when StopDrawing() is called 
 PixelBuffer.l      ; Address of the memory pixel buffer (DirectX)
 Pitch.l            ; Pitch
 Width.l
 Height.l
 Depth.l
EndStructure

Structure PB_GadgetStructure
 Gadget.l    ; OS Gadget pointer (HWND)
 *VirtualTable.GadgetFunctions
 CustomData.l  ; Can be used to store extra infos on this gadget
 CustomData2.l ; Can be used to store extra infos on this gadget
EndStructure

Structure GadgetFunctions
 FreeGadget
 GetGadgetState
 SetGadgetState
 GetGadgetText
 SetGadgetText
 AddGadgetItem
 AddGadgetItem2
 RemoveGadgetItem
 ClearGadgetItemList
 ResizeGadget
 CountGadgetItems
 GetGadgetItemState
 SetGadgetItemState
 GetGadgetItemText
 SetGadgetItemText
 OpenGadgetList2
 GadgetX
 GadgetY
 GadgetWidth
 GadgetHeight
 HideGadget
EndStructure

Structure PB_StructureDataBase
 Connection.l   ; OS ODBC Connection identifier  (SQLHDBC)
 Statement.l    ; OS ODBC Statement identifier  (SQLHSTMT)
EndStructure
  
and all the other strucutures please...

The same would be nice for internaly shared purebasic variables or whatever you want call it (in an own tab), like... Listing all libnames and when pressing on the name you get the info for each lib, like...

Code: Select all

Window
 _PB_Window_ObjectsNumber
 _PB_Window_ObjectsArea
 _PB_Window_Current       ; Current used window
 _PB_Window_EventType

DataBase
 _PB_DataBase_ObjectsNumber
 _PB_DataBase_ObjectsArea
 _PB_DataBase_CurrentObject  ; Memory address inside the  _PB_DataBase_ObjectsArea memory bank which points to the current object

and all the others...

[va!n]

- Small and fast DirectX9 (2d/3d) commands
- Optional change between creating Win32 and Win64 PE-Header, since latest FASM version support it!

[blueznl]

i'd rather have an option to settle for dx4 / dx7 / dx9 compatibility, wouldn't that make more sense than different optimized commands each dedicated to a specific environment?

[va!n]

@blueznl:
sure it would be nice to select what DX version your app should compiled for! but i think in today times it would make to support mainly the newest technic and this is DX9 and not DX3 or DX4 for NT4 support! (who really want play DX games or show DX demos on an NT4 system? I think most people which are interested in games and demos may have a modern pc with an modern graphic card (supporting DX9 technology) as DX9 is standard with every WinXP

ON the other hand, i often read and heared that developing for DX9 is a lot more easier with less coding and more performance as versions before DX9! Also DX9 based programs may be smaller!?

Btw, when i want code any DX related programm (game or demo) i would like to support and use the latest technic as its possible and not stoping by reaching the maximum of DX4 / DX7 features! Lets look forward and not backwards... technology is going to fast forwards...

[MrMat]

Wishlist for v4.0:
A scroll lock for the debugger

[Dare2]

A command like GroupGadgets would be nice. This command would associated clumps of gadgetry and allow some actions to then be applied to all gadgets in a group. Gadgets should also be allowed to belong to more than one group.

It could be used for HideGadget, DisableGadget, etc, to do block actions.
eg:

Code: Select all

...
  OptionGadget(#Option1,X,Y,40,20,"ONE")
  OptionGadget(#Option2,X,Y,40,20,"TWO")
  OptionGadget(#Option3,X,Y,40,20,"Whee")
...
  ButtonGadget(#ButtonA, etc)
...
  ComboBoxGadget(#ComboZ, etc)
...
  GroupGadgets(#Group1, #Option1,#Option2,#Option3[, ...])
  GroupGadgets(#Group2, #ButtonA,ComboZ,#Option3[, ...])
...
  HideGadget(#Group2,#True)
  SetGadgetState(#Group1,1)

Some of this can be done in other ways (eg a procedure that does all the hiding/disabling/etc of a clump of gadgetry) but it would be neat.

For OptionGadgets it is a very intuitive way of lumping associated radio buttons together. So if one is chosen others in the group are unselected.