PureBasic Forums - English

Posted: **Thu Mar 07, 2013 8:56 pm**

Remarkable!

and a lesson in OOP to boot

I haven't a clue...

Posted: **Thu Mar 07, 2013 10:46 pm**

netmaestro wrote:Event testing is updated to include leftclick and you're right, it's quite useful. Now the only unanswered question is whether or not it's still working properly on Mac and Linux.

The "redesigned" code works fine now also on my MacOS 10.5.8

Means clicking on the trackbar (fader is updated after releasing the left mouse buttons) as well clicking inside the canvas does now correctly update the faders.... Well done! Thanks

Posted: **Sat Mar 09, 2013 5:16 pm**

Netmaestro or whoever is able, do you wont to enlighten this magic code part a bit more ?

How does one field of a structure (vTable) get multiple proc-adresses ?
It's just one pointer and so how can it receive multiple proc-adresses ? That's what's happening there I believe.
InitializeStructure has probably something to do with these I suppose, but...

Code: Select all

*this.FADER = AllocateMemory(SizeOf(FADER))
  InitializeStructure(*this, FADER)
  *this\vTable = ?FADER_Methods
  
   DataSection
   FADER_Methods:
   Data.i @Fader_Canvas(),
          @Fader_SetColumn(),
          @Fader_GetColumn(),
          @Fader_RedrawColumn(),
          @Fader_ProcessEvents(),
          @Fader_Move(),
          @Fader_Free()
 EndDataSection

I suppose, I can imitate this setup, but understanding what is going on, how much elements (proc-adresses) can be added and so on, that's another thing.

Thanks.

Posted: **Sat Mar 09, 2013 5:31 pm**

Joris wrote:Netmaestro or whoever is able, do you wont to enlighten this magic code part a bit more ?

How does one field of a structure (vTable) get multiple proc-adresses ?
It's just one pointer and so how can it receive multiple proc-adresses ? That's what's happening there I believe.
InitializeStructure has probably something to do with these I suppose, but...
Code: Select all
*this.FADER = AllocateMemory(SizeOf(FADER))
  InitializeStructure(*this, FADER)
  *this\vTable = ?FADER_Methods
  
   DataSection
   FADER_Methods:
   Data.i @Fader_Canvas(),
          @Fader_SetColumn(),
          @Fader_GetColumn(),
          @Fader_RedrawColumn(),
          @Fader_ProcessEvents(),
          @Fader_Move(),
          @Fader_Free()
 EndDataSection
I suppose, I can imitate this setup, but understanding what is going on, how much elements (proc-adresses) can be added and so on, that's another thing

It reflects the Interface. *vTable simply points to the start of a 'vector Table' which holds the addresses for all of the methods (in the same order) that were defined in the Interface.

Compare the table above with the interface code:

Code: Select all

Interface iFADER
  canvas()
  SetColumn(column, level)
  GetColumn(column)
  RedrawColumn(column)
  ProcessFaderEvents(*fader.iFADER)
  Move(x, y)
  Free()
EndInterface

The structure that is used and initialized is setup with at least one field, the *vtable, first. Any additional structure fields there differ according to the methods and interactions defined for the object.

Posted: **Mon Mar 11, 2013 3:17 pm**

It might sound silly, but I'm still wondering why the use of 127 images is needed ?
I originally had one image as source and all others are copies to one surface (BitBlt), for each type of fader, which can hold (in this case) 127 of them.
It's probably a matter of resources, but one big surface instead of 127 small ones wouldn't that make a big difference, if even more would be added ?

I'm thinking of a program in which a user can add his own bunch of faders, selecting one from a preset design and connect them with some function (like in a sort of form editor).

Code: Select all

Procedure New_Fader(x, y)
  
  fg_iCol = CreateImage(#PB_Any, 6, 128) 
  ...  
  For i=0 To 127
    temp = GrabImage(fg_iCol, #PB_Any, 0, 127-i, 6, i+1)
    *this\iLevel(i) = CreateImage(#PB_Any, 6, 128)
    StartDrawing(ImageOutput(*this\iLevel(i)))
      Box(0,0,6,128,$D1D1D1)
      Box(1,0,4,128,$EFD6AD)
      DrawImage(ImageID(temp), 0, 128-i)
      FreeImage(temp)
      For j=3 To 123 Step 4
        Line(0,j,4,1,$EF1010)
      Next
    StopDrawing()
  Next
  
  FreeImage(fg_iCol)
...

Thanks.

Posted: **Mon Mar 11, 2013 5:06 pm**

There is one image built and stored for each possible level. There would never be a reason to have more than 128 of them regardless of the number of columns in a fader. Each image is small and the memory used is negligible and the main benefit to this approach is speed. If these images were not pre-built and available, the code you're showing would have to be executed from GrabImage down to StopDrawing at every single mousemove. As it is, the image is chosen and blitted to the canvas and we're ready for the next one. No, this one is not negotiable, changing it would result in a serious performance drop.

Posted: **Mon Mar 11, 2013 6:37 pm**

netmaestro wrote:There is one image built and stored for each possible level.
...

Wooops, I didn't noticed that quit well.
I was already trying to do partly redrawing of the fader image, but no go, as the complete image is just drawn in a smaller size. Then it make sense to have an image for every value : SPEED, as the drawings commands are many for a bit nice picture. Yet, quit sad, there isn't a way to fast redraw a part, except a non-crossplatform BitBlt. I'm thinking of that other source where you could do it, inside the same output... we need also into another output.
Has this never been a requested ?

Posted: **Mon Mar 11, 2013 6:46 pm**

Joris wrote:
netmaestro wrote:There is one image built and stored for each possible level.
...
Wooops, I didn't noticed that quit well.
I was already trying to do partly redrawing of the fader image, but no go, as the complete image is just drawn in a smaller size. Then it make sense to have an image for every value : SPEED, as the drawings commands are many for a bit nice picture. Yet, quit sad, there isn't a way to fast redraw a part, except a non-crossplatform BitBlt. I'm thinking of that other source where you could do it, inside the same output... we need also into another output.
Has this never been a requested ?

Just to be clear, what do you mean by 'non-crossplatform BitBlt' ? PB DrawImage() uses BitBlt() on Windows, so did I miss something ?

Posted: **Mon Mar 11, 2013 6:49 pm**

Fred wrote:Just to be clear, what do you mean by 'non-crossplatform BitBlt' ? PB DrawImage() uses BitBlt() on Windows, so did I miss something ?

@Fred: He means that he thinks BitBlt() is the only way to accomplish the task but that it is non-crossplatform. He is looking for a way to draw a clipped image that would also be cross-platform.

Posted: **Mon Mar 11, 2013 6:58 pm**

Demivec wrote:@Fred: He means that he thinks BitBit() is the only way to accomplish the task but that it is non-crossplatform. He is looking for a way to draw a clipped image that would also be cross-platform.

Indeed, but also speed is quit important herein.
PB DrawImage() doesn't allow to take a part of the image, (it becomes resized instead of 'cut out').
(Pay attention I'm in a learning fase still.)

Maybe just a flag or a DrawingMode() : no_resize, could fix things.
Yet... x-y-w-h it still wont be complete.

Posted: **Mon Mar 11, 2013 7:09 pm**

Joris wrote:
netmaestro wrote:There is one image built and stored for each possible level.
...
Wooops, I didn't noticed that quit well.
I was already trying to do partly redrawing of the fader image, but no go, as the complete image is just drawn in a smaller size. Then it make sense to have an image for every value : SPEED, as the drawings commands are many for a bit nice picture. Yet, quit sad, there isn't a way to fast redraw a part, except a non-crossplatform BitBlt. I'm thinking of that other source where you could do it, inside the same output... we need also into another output.
Has this never been a requested ?

It would be great to have a convenient method of clipping a drawing. Still, I don't think it is too much of a speed hit to simply draw the portion again. This is what I did in the first code sample that I posted in your original thread requesting a solution to this need. The code did all of the things that you demonstrated you needed and seemed to function just fine. Refining it to add more customization or converting it to use an interface (as netmaestro did) would not be too difficult.

Posted: **Mon Mar 11, 2013 7:09 pm**

Ok, I see.

Posted: **Mon Mar 11, 2013 9:33 pm**

Demivec wrote:It would be great to have a convenient method of clipping a drawing. Still, I don't think it is too much of a speed hit to simply draw the portion again. This is what I did in the first code sample that I posted in your original thread requesting a solution to this need. The code did all of the things that you demonstrated you needed and seemed to function just fine.

Demivec, I have no comment on the code of Netmaestro or yours, but what I didn't tell...
All is based on this one example of fader image which was shown, while I also use more complex fader images and in more or less numbers, sizes and spaces between them.
These become moved while there is also a timer calling a proc (1/1000s), which may absolutely not become interrupted.
So, speed is very important in the first place, the timer-thing in PB is a later concern. I hope this makes a bit more clear. And, thanks again for the help, also on the interface explanation.

Posted: **Mon Mar 11, 2013 11:12 pm**

Joris wrote:Demivec, I have no comment on the code of Netmaestro or yours, but what I didn't tell...
All is based on this one example of fader image which was shown, while I also use more complex fader images and in more or less numbers, sizes and spaces between them.
These become moved while there is also a timer calling a proc (1/1000s), which may absolutely not become interrupted.
So, speed is very important in the first place, the timer-thing in PB is a later concern. I hope this makes a bit more clear. And, thanks again for the help, also on the interface explanation.

@Joris: You have made things clearer.

My comment was directed at the idea of speed. Netmaestro's code is a great demonstration of one way to accomplish the things you originally requested but has some challenges with speed of redrawing as it is currently implemented. All one has to do is move the trackbar up or down to notice this.

You mentioned some concern over why his code stored many images for displaying the column values and used the bitblt() functionality has a desirable thing, both for speed and ease of use.

I was trying to address the idea of speed also as well by reminding you that a previous code sample of mine simply redrew the column from scratch each time it changed and didn't store any images. It was simply to show that there were other options that were quick and uncomplicated. My intention wasn't to muddy the waters.

Posted: **Tue Mar 12, 2013 10:10 am**

Demivec wrote:My intention wasn't to muddy the waters.

I was a bit scared for that and I don't wont that too.

Demivec wrote:Netmaestro's code is a great demonstration of one way to accomplish the things you originally requested but has some challenges with speed of redrawing as it is currently implemented. All one has to do is move the trackbar up or down to notice this.

Now that I understand his code for 99% I know it is the best solution in any way : nice image, speed, redrawings, etc. But doing a research is part of learning and that sometimes ends up in 'silly questions' (beside the need to translate my words and thoughts). Me, I'm used to BitBlt for this kind of things and find it still hard to believe it isn't included for a crossplatform way. I got to accept that, but sorry to say, it feels a bit like going backwards having no other solution. Maybe an elucidation : think about a nice audio volume meter...
(To substantiate a request, nothing more.)

Thanks.

PureBasic Forums - English

128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned

Re: 128 Slider/Faders Include Crossplatform - Redesigned