Jump to content

XWindows Dock v5.2.3


BOBAH13

Recommended Posts

  • Replies 2.9k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

could somebody convert this to new dock please

Do you have permission for updating from the original creator of this skin (sorry, I don't recall who created it)?

I could do the conversion but I'm unsure if posting it'd be allowed...

p.s.: it doesn't have a different icon for 'StackOff'; if I'm allowed converting it, should I keep it or use another, better fitting one?

Link to post
(PS: I still could need Sources of the existing Docklets to get into development faster...)

I'm not likely releasing sources of XWeather docklet, sorry.

But, here is sources of XClock: ;)

http://www.matiasmoreno.com.ar/XClock-sources-2008-11-07.rar

I encourage people to not have the brilliant idea of merely adding an About dialog to this and republish it. It's not meant to be open source.

I do encourage coders to use this as an aid to write other docklets (even a digital clock) (as long as it is skinnable ;)).

Edit:

BTW the sources say icons_bug, it is not really a bug yet (XWindows Dock does not dispose the icon, but the documentation (I mean XDockletSrc.pas) doesn't specify if the docklet is responsible to dispose the icon).

Link to post

Thanks mate, that's enough. I'm working on a "show desktop"-Docklet (with some special features), but currently I have a problem: The docklet is working fine, when I first add it to the dock, but after i restart the dock, the docklet "is gone" (there still is an empty space, but it has no functionality and only the default context menu is shown). If i delete the empty space via context menu, and add my show-desktop again, it's working again. But only until the next restart...

The same happens with the sample code from XDockletSrc.pas

Any idea, what that is?

EDIT: The mysterious empty-space docklet is a default shortcut-docklet. I can edit it just like any other shortcut on my dock. Why was my own docklet overwritten by this one?

EDIT2: I found the source of the problem, but not the solution:

XDocklet.SetName('XDesktop'); is somehow misinterpreted. It messes up the name for the Docklet (see screenshot below). Thats why XWinDock can't find it at a restart. If I use XDocklet.SetName('X'); everything is working fine, because one letter can't be messed up. What's the problem here?

post-90085-1226064147_thumb.jpg

XDockletSrc.pas.zip

Link to post
EDIT: I did get the GDIPAPI installed, but the compiler shows an error in XDockletSrc.pas on

line 130: GdipCreateSolidFill(ARGBMake(255, 0, 0, 0), Brush);

E2003, ARGBMake is undeclared.

Mantonga, can you help me? I guess i still have some problems with GDI+...

Ah, sorry atreiu, I use this pack but I really didn't test it with docklets :confused:

Link to post
EDIT2: I found the source of the problem, but not the solution:

XDocklet.SetName('XDesktop'); is somehow misinterpreted. It messes up the name for the Docklet (see screenshot below). Thats why XWinDock can't find it at a restart. If I use XDocklet.SetName('X'); everything is working fine, because one letter can't be messed up. What's the problem here?

It looks like a Unicode - ASCII problem.

Try these:

XDocklet.SetName(String('XDesktop'))

XDocklet.SetName(WideString('XDesktop'))

One of these should do the stuff. I'm at work now so I haven't access to the code.

I've compiled XDocklet (the example) at home and it works, so it is strange it doesn't work in your case.

What Delphi version are you using? Check that your Delphi version uses 8 bit chars for Strings.

I can't remember if XDocklet.setName uses strings or widestrings as arguments.

BTW for anyone interested in writing C++ XDocklets, I've made some progress on headers and stuff.

To call a Delphi object method, you'd do:

void (xdocket_method *) (void * this, ...);



xdocklet_method (xdocklet, ...)

To create a Delphi compatible string:

struct string {

int ref_count;

int str_length;

char data[0];

};



void * new_string (const char * text) {

int str_length = strlen(text);

struct string * str = malloc (sizeof (struct string) + str_length + 1);

str->ref_count = 1;

str->str_length = str_length;

strcpy (&(str->data), text, str_length);

return &(str->data);

}



void free_string (void * str) {

char * p = str;

p -= sizeof(struct string);

free (p);

}

To pass the string to some method:

void (xdocklet_setstr *) (void * this, int Index, void * string);



void * str = new_string ("Foo bar");

xdocket_setstr (XDocklet, Index, str);

free_string (str);

Please note I haven't reverse-engineered WideString strings yet, that's why I haven't published a XDocklet.cpp yet, but I hope I can soon.

First version will probably use MinGW, next I'll try to compatibilize example with Visual C++ 2005.

Link to post
It looks like a Unicode - ASCII problem.

Try these:

XDocklet.SetName(String('XDesktop'))

XDocklet.SetName(WideString('XDesktop'))

One of these should do the stuff. I'm at work now so I haven't access to the code.

I've compiled XDocklet (the example) at home and it works, so it is strange it doesn't work in your case.

What Delphi version are you using? Check that your Delphi version uses 8 bit chars for Strings.

I tried both of your suggestions, changed nothing :-(

I don't understand this... There is nothing different from your line in Clock-Docklet.

I'm using Delphi 2009.

PS: XDocklet.setName uses strings, not widestrings as arguments. Widestring result in an error at XWinDock-Startup.

Link to post
atreiu: We programming using Delphi 7... so of course you can have same problems...

AH! Good hint! Delphi 7 uses AnsiStrings as Strings. Delphi 2009 uses UnicodeStrings as Strings.

I just changed everywher in the declaration to:

SetName: function(const Name: AnsiString): Boolean stdcall of object; // XDocklet's name

(AnsiString instead of String)

And now its working. Thanks you both! :)

Link to post

@bobah: I think I know what causes that 1 pixel vertical line to appear between 'MiddleBorder' and 'RightBorder': original transparency of those images (dock background).

I know you recommended not using transparency, as the dock itself controls it, but this can be too limiting at times; so, I ask you to verify the possibility of allowing the background to have transparency in next releases of the dock. Please, let us know if you can confirm that this is indeed the culprit of the problem.

Edit:

20983pk4.gif

Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...