PureBasic Forum

Probably because there is only one default type at all. And that's .i, as you wrote.
And what has this got to do with the docs?

Regards, Little John

but .i aint no float aight?

wouldnt it be easier to write:

instead of:

and yes, its off-topic, thats why i will stop here.

c ya,
nco2k

> btw, why isnt there a default (.i like) type for floats? .f on 32bit and .d on 64bit. isnt .d 'faster' on 64bit?

No. Both x86 and x64 have the same floating point unit, so it makes no difference.

ah thanks.. so it was just a rumor then.

c ya,
nco2k

Now I see what you mean. It was a misunderstanding.

Regards, Little John

Update entry 'Data' to correct examples and text describing the storing of memory addresses so that they use the Integer (.i) type instead of Long (.l). This will keep things accurate for both 32-bit and 64-bit environments.

Here is some of the sample text demonstrating what needs to be changed:

Hi Andre,
Great work on the docs, I like the concise style in which they are done.

Friendly reminder:
I noticed in the latest beta 6 for 4.40 that there is still no mention in the help file of the new gradient drawing functions:
LinearGradient(), BoxedGradient(), CircularGradient(), EllipsicalGradient(), ConicalGradient()

Log()


A function cannot return "the Log", but only a logarithm for a particular base.

Since Log() calculates the logarithm for base e, it should read:
Returns the natural logarithm of the given number.

Regards, Little John

@LJ: Amazing, how many things you find, but much more important: I´m soooo happy you have never been a teacher of mine at school

The manpage of OSVersion() is missing "#PB_OS_Windows_7"

On a sidenote - the "About" requester of PB 4.4B6 still says "2008" at one place.

EventDropAction()

Shouldn't it be the drag target, that is responsible for removing the original data

Otherwise, how would you signal the drag source to remove the original data or not

This is correct. How should the drag target be able to remove data from another program ?

The DragXXX() functions indicate to the source wether the drag succeeded or not so it can take the appropriate action.

I'd like to use an example to get this straight:

I'm using an application with a window with a StringGadget (txtBaseDir).

Here I want an easy way to get a path to a file or folder.
Therefore I use:Now I drag some folder from Konqueror onto the StringGadget.

As Konqueror is where I got the folder from, I consider it to be the source, right?

The target then would be my StringGadget.
(As it is the place I drag the folder to)

In the eventloop I evaluate a #PB_Event_GadgetDrop to my StringGadget
and execute some procedure.

In this case I do not want the folder to be deleted.
(It does not get deleted.)

But if I wanted the source file to be deleted, I would need to code the act of deletition like somewhere in my target procedure.
As here is also the only place, where I know when I don't need the source anymore.

I'm using another PB application that contains file paths in a ListIconGadget.
I can drag them from there (my app being source) to the trash.
The trash now considered target.

Nowhere in this source app have I coded any deletion or such!
But files dragged from here to the trash, do get moved to the trash.

This is fact.

Unless you come up with an alternative way to define source and target,
the help text is wrong.

Files are different because you do not drag the actual file but only the file name. So whatever is to be done to the file itself has to be done by the target (the DragFiles() help page mentions this). For all other types of content, the source is responsible for the deletion.