TextEdit Gadget

[Polo]

Trouble is I cannot really ship this as a DLL, as it uses Purebasic event loop. I'll try to think at what I can do!

[slagusev]

Where can I download?

[Polo]

Hi there, sorry you can't download it, I never really finished it / polished it enough I'm afraid!

[Zach]

That's a shame, I was really looking forward to trying it out. It was very promising

[jesperbrannmark]

C'mon Gaetan....
You know this is to good to be hidden away from the world.....
Trust me, its good enough to be used to 1000+ people daily in a commercial system - its good enough to be released.
Stop being such a perfectionist

[Polo]

C'mon Gaetan....
You know this is to good to be hidden away from the world.....
Trust me, its good enough to be used to 1000+ people daily in a commercial system - its good enough to be released.
Stop being such a perfectionist

I still haven't find a way to release it to a DLL or something like this unfortunately, and with the workload I have at the moment at my job it's been quite difficult

[luis]

Trouble is I cannot really ship this as a DLL, as it uses Purebasic event loop. I'll try to think at what I can do!

Don't know if feasible in your case, but once I had a similar problem.
I worked around it by putting a single procedure outside the DLL in a include file, let's call it MyWindowEvent().
The procedure invokes WindowEvent() from the client program, and inject the messages inside the DLL calling an helper proc in the DLL.
The helper proc then can communicate back if it has processed the event or not, you can pass native #WM_ message and/or #PB_Event messages, etc. there are many possibilities.
You have just to call MyWindowEvent() instead of WindowEvent() in the client program.

[Polo]

From what I understood it is not possible to communicate with gadgets created by a DLL. I think that was the problem at the time!

[luis]

I cannot comment on that, I've never tried, but I think many limitations can be bypassed by just letting something in the client program in the source form, the minimal required to be able then to pass what required to the DLL.
In another case I wanted to be able to visualize images create in my DLL using the object viewer available in the debug tools.
PB can't do that if createimage is called inside the DLL. So I've registered a "create image" in the client, and when the DLL needed to create an image just called the helper in the client. That way the ID was recognized by PB debug tools, and what I wanted to do with the image in the DLL was still just my business.
Not saying is the solution to all problems, but this kind of method until now solved (most of) my problems about DLLs.
Just wanted to mention it, maybe can be an idea worth exploring for someone else.

[srod]

@Polo:

it looks like BindGadgetEvent() could be the answer to your problem here. I have just tested on Windows and it works fine. You'd have to test on other platforms.

Compile the following to a DLL :

Code: Select all

Global id

Procedure events()
  If EventType() = #PB_EventType_LeftButtonDown Or (EventType() = #PB_EventType_MouseMove And GetGadgetAttribute(id, #PB_Canvas_Buttons) & #PB_Canvas_LeftButton)
    If StartDrawing(CanvasOutput(id))
      x = GetGadgetAttribute(id, #PB_Canvas_MouseX)
      y = GetGadgetAttribute(id, #PB_Canvas_MouseY)
      Circle(x, y, 10, RGB(Random(255), Random(255), Random(255)))
      StopDrawing()
    EndIf
  EndIf
EndProcedure


ProcedureDLL AddCanvas(x, y, width, height, windowID)
  result = UseGadgetList(windowID)
  id = CanvasGadget(#PB_Any, x, y, width, height)
  BindGadgetEvent(id, @events(), #PB_All)    
  UseGadgetList(result)
EndProcedure

This is the PB user manual canvas gadget demo wrapped into a dll.

Now the client (stick it in the same folder as the dll) :

Code: Select all

Import "dll.lib"
  AddCanvas(x, y, width, height, windowID)
EndImport


If OpenWindow(0, 0, 0, 220, 220, "CanvasGadget", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  AddCanvas(10, 10, 200, 200, WindowID(0))
  Repeat
    Event = WaitWindowEvent()
  Until Event = #PB_Event_CloseWindow
EndIf

On Windows, the dll receives all the events it needs in the event handler and without having to run an event loop itself.

If it works on other platforms then I would say that you can indeed stick your gadgets into a dll.

[Polo]

It actually works on OS X!
Seems like I should try to have a go at updating my lib!

[srod]

That is good. I had my doubts about OSX.

Must admit that I only deal with open source controls, but it does open up some interesting possibilities nevertheless.