Page 12 of 16
Posted: Tue Oct 11, 2005 5:49 pm
by Straker
Ok, back to the topic.
Here is my gadget event wishlist, please all native event flags:
#PB_EventType_MouseOver (or MouseIn)*
#PB_EventType_MouseOut (or MouseLeave)
#PB_EventType_MouseUp
#PB_EventType_MouseDown
#PB_EventType_MouseMove (within gadget)
*I know this MUST be possible natively, because the ToolTip feature is somehow trapping when it is over a control - so PB is doing this internally anyway.
And for the string Gadget:
#PB_EventType_Changing (fires with each character typed)
Yes, I know I can do this in Windows via API calls which I am very familiar with, but I would like my Linux apps to have the same behaviour.
Just trying to keep PureBasic "Pure".
Posted: Tue Oct 11, 2005 6:03 pm
by Polo
A total rework of the gadget lib, but I think it's already planned ?
Posted: Thu Oct 13, 2005 1:47 pm
by Flype
Just an idea while i'm programming...
you know SizeOf(MyStruct)
you know OffsetOf(MyStruct/fieldName)
what about IndexOf(MyStruct,index.l)
a little snippet, for showing what i'm talking about:
Code: Select all
Structure PEOPLE
firstName.s
nickName.s
birthDate.s
comment.s
EndStructure
MyItem.PEOPLE
For i=0 To 3
Debug IndexOf(MyItem,i) ; for easy field-debugging
Next
line$ = ""
For i=0 To 3
line$ + IndexOf(MyItem,i) + Chr(10) ; for easy field-appending
Next
AddGadgetItem(#ListIcon,-1,line$)
Posted: Thu Oct 13, 2005 5:39 pm
by va!n
i would like to have following two commands for ASM sections...
just a small example...
Code: Select all
CompilerStartASM
push eax
push edx
!MOV eax, [v_StatusString]
!MOV edx, [v_playing]
!fild qword [eax]
!fistp qword [edx]
!ADD edx, 8
!MOV byte [edx], 0
pop edx
pop eax
CompilerEndASM
Posted: Thu Oct 13, 2005 7:22 pm
by Psychophanta
...i think we are starting to say ...mmm... vanities...
Posted: Thu Oct 13, 2005 7:38 pm
by va!n
Psychophanta wrote:...i think we are starting to say ...mmm... vanities...
I dont know why it may be vanities? I think this would help some people coding tools/plugins (like source formating and other tools i.e) and for the user the souce can be more readable while having a better overview!
Even for Fred and his compiler this could be helpfull to differentiate between purebasic and ASM parts in the source... BlitzBasic Amiga had something like this too! I would welcome it...
[Edit:]
And dont forget, this could give you the possibility to have one source for with inline ASM for different CPUs like PPC and x86 for example... just an idea...
Code: Select all
CompilerIf X86
CompilerStartASM
; x86 code
CompilerEndASM
CompilerEndIf
CompilerIf PPC
CompilerStartASM
; PPC code
CompilerEndASM
CompilerEndIf
Posted: Thu Oct 13, 2005 7:40 pm
by remi_meier
It would give you a better overview and you just wouldn't have to enable InlineAsm for the whole document but just for a little procedure! And if it's easy to implement, why not?
Posted: Thu Oct 13, 2005 8:06 pm
by Psychophanta
remi_meier and va!n:
Choose a different color in the editor for ASM commands. That's all what you need to make code more readable and differenciable!!!
Posted: Thu Oct 13, 2005 8:23 pm
by remi_meier
I have different colors for ASM commands, but it's not the same!
And it's not only this! Like I said, at the moment you have to enable Inline
Asm for the whole project, with the new commands you could use asm
in procedures without having the lack of not be allowed to use variables
like 'mov', 'add', and so on..
Posted: Sat Oct 15, 2005 8:22 pm
by va!n
What do you think? We all know there are some nice 3rd part libs created with purebasic and talibite! The idea to create PureBasic libs with PureBasic isnt bad but at least i am not really happy with the result! (el_choni i dont want fight you nor talibite here!)
The licence for most of this purebasic libs are free but the mainproblem is that not every author will release his lib-sources too! In some cases this is still ok! (btw, you can use his libs for free but the author dont spread the source (sometimes weeks or months of work) as in normal business life
We all know, sometimes people may find a new bug in the latest PureBasic compiler and it will be fixed for the next release! (fred, i dont want fight you nor purebasic here!)
This is the point we all should think about! Even the PureBasic lib format has been changed in the past! If someone release a PureBasic lib created with PureBasic and Talibite and release it only as lib (without source) it may work for the actuatl PureBasic version it has been compiled/created for!
But what happens, when the author of the lib will stop continue the developing of his lib and when the day comes, where PureBasic once again dont like the LibFormat the lib was created for???
You have once again a useless lib, because it may not work with future PureBasic versions and if the lib was created by an old bugy version of the PureBasic compiler - the bug will never be fixed! Even when futuer compilers may optimize stuff better and better - we get nothing from this! Strange! If you used the lib for one of your big projects, your project will die! Is this what we want?
I dont think so! So i thought about this and i come with following realisable idea! Some C/C++ coders may know the system! For this languages are tons of routines available as so called *.lib (standard dynamic libs) and its a special format, you can link the stuff to your project but people cant see/change your source! (its like a protected source but still useable for everybody!)
One nice idea would be to be able to create so called *.lib files with PureBasic but i think Fred would not like this idea! Because this idea has a little "purebasic licence problem"!!! You could use the original purebasic 2D commands and create your own *.lib and use it in your c++ project! However the *.lib format is a standard and it would be nice to have this for PureBasic too!? Fred? :roll:
One other way without breaking the "PureBasic licence problem" would be, that PureBasic has its own *.lib format, for example called *.plb or *.plib
Your source will crypted or converted (however) to a special purebasic format (so your source is still protected and unreadable for other peoples) but people can include your *.plib in their purebasic projects and the purebasic compiler still link your *.plib!
So the content inside *.plib isnt compliled - every new PureBasic compiler release, can optimize your *.plib (the code inside) to the best and fastest as possible and you dont have to slep around old compiler bugs inside your lib and non optimized libs! (sorry, for the bad english!)
I hope you know what i mean and that my explaining isnt to bad!? I would like to hear your opinions about this... Lets look to a nice future for own created *.plib(s)
Posted: Sat Oct 15, 2005 10:35 pm
by Shannara
Hear Hear, I second that wish!
Posted: Sat Oct 15, 2005 10:48 pm
by traumatic
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?
Posted: Sat Oct 15, 2005 11:30 pm
by Blade
I understood that the .lib files are a sort of pre-compiled files.
When used, they are still compiled with your source, having the benefit to be compiled with the latest PB compiler...
You still can't edit the lib source.
Well, sounds nice, considering that we can't force anyone to give their sources.
Posted: Sun Oct 16, 2005 12:06 am
by Dare2
I wish I might I wish I may have the wish I wish today
It would be nice to be able to link object and lib files. This could perhaps be done with new command-line parameters (and with the ability to set this in the IDE) and a declaration. Example:
LINK [filelist]
or
LINK:file LINK:file
or
whatever format turns people on.
And in the source:
External procname.type ( par.type ....)
or
LinkedProc procname.type ( par.type ....)
or
whatever syntax presses the right buttons.
Posted: Sun Oct 16, 2005 12:26 am
by ts-soft
I wish this:
Code: Select all
IncludeLib "file"
IncludeResource "file"
IncludeResourceSkript "file"