to lazarus. At somepoint someone mentioned that ppc386 is just a shell that calls and uses the compile.pp unit. I don't know if you want to actually include the compiler into lazarus at this point but it is probably howit should be done in the future.

I know that this didn't answer your immediate question but you might want to look into this so that you code things with this in mind for the future. :-)

Why don't you just use the appropriate Exec function and then use an #ifdef to determine whether to use the Linux unit or the Dos unit?

the unit(s) that require it, all is fine. But if it's compiled beforehand and then you try to compile a unit that requires it, that triggers the error. So could it be writing an incorrect symbol table for graphics.ppu?

'../inc', what in fact should be '../i386/inc' (in fact the 'i386' is coming from a variable, but I can't remeber the name)

Pascal

_________________________________________________________ Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

GTK, or volunteering to the GTK team to do it yourself. Most of the time, I would think you would just have to live without it, but it shouldn't be ruled out.

Jeff.

To implement this with a WindProc, instead of passing the LCL self to the GTK object, instead pass the xxxCallbackInterface self to the object. The xxxCallbackInterface has the LCL object Self stored. Interfaces It takes the GTK callback information and instead of retrieving the LCL self, it instead gets the xxxCallbackInterface self. From there, it calls a Transmit message routine, which reformats the callback data to an LCL message, and then calls the LCL Self WindProc. This WindProc then calls Dispatch.

This would give each LCL component its own WindProc, and only replace the LCL self with a new xxxCallbackInterface self in the GTK callbacks. Two additional layer of redirection, I suppose, the xxxCallbackInterface and the WindProc itself.

Is this not possible? What am I missing?

That gets you to the opposite of my first attempt at making Win32 look like GTK. There, I had one "true" (in the Win32 sense) WindProc. I can tell you from the other side, this is definitely -NOT- the way to go.

Jeff.

deisgned in a way that we (the users) would have to do stuff we should not have to do.

Also, I'm alot for close compatibility with Delphi.. but I'm more for innovation and efficiency. Perhaps having a few units that will basically do stuff like LM_Something = WM_Something, abstracting LCL to the same interfaces as the VCL, etc.

Maybe there is a way one component could be built with 2 interfaces, and in delphi compatibility mode it would abstract Delphi's interface.. this sounds dumb, but that way we'd be independent from borland's "innovations" and especially backward compatibility, which is cool since we'll be able to compile Lazarus apps under alot of OSes eventualy.. Delphi compatibility mode would only be usefull for porting Delphi apps.

I'll try to get my Linux connected to the net, and then I can start looking into helping with some coding.. =o)

Alex

--------------------------------------------------- Powered by Bell Canada / Commandit� par Bell Canada http://www.bell.ca/

Removal from the mailing list.

If you want to be removed from the mailing list just click the link below.

If you aren't using a browser that can link to your mail then just send mail to: and place the word unsubscribe in the subject line.

Jeff.

it seems that Boland are very keen, and getting encouraging responses from distributors, to have their shared libs already on peoples machines through the Linux distributors. If this happens the way they plan then Delphi/Kylix programs will be small and transportable. As they could never get MS to include Borland libs as part of the dll bloat of windows this is a big issue for them and I think they would regard Wine as a retrograde step.

Peter

compiler. I hope version 1.0 comes soon ;-)

I could not find a 0.99.12b version on my computer anymore, but I have a november 99 snapshot, which could do the trick, so I am hopefull, you could make this work with 0.99.12b.

Vincent Snijders.

When a program is started the application object gets created and and the initialize routing is called on the interface object. Here is where we tell the engine to create a engine instance. From then on the lcl will pass a message to the IntSendMessage routine telling the widget engine to do various things depending on what was passed. For instance the routine may get a message to create a form in that case lcl_win32_create_widget gets called and it internally creates a form. It will pass back a integer value "we'll call it the hwnd" which is the index of the component in the list. Inside of the interface object we set the LCL TComponent handle with that returned value because that is what we are going to use to access the instance. Now in the library you will need to do something like lcl_win32_reparent_widget(hwndparent, hwndchild: integer) and that will inturn set the parent of the child to the parent. Then you add something like lcl_win32_set_bounds(hwndwidget: integer;x,y,top,left: integer) so internal you just grab that widget from the list and set the properties. Then you need to add a event hook I think I coded the stub into it but did not finish it. Something like lcl_win32_hook_mouse_move(hwndwidget: integer; fproc: pointer) You then assign a handler internal which will call this fpc method pointer. I know this sounds like a lot of stuff but it is pretty simple to implement.

Cliff

Remember Delphi Net components include more than just sockets ...

Network components are one of the four basic CLX groups in Kylix (the others being; non-visual, visual, and database) .

Kevin Flanagan

On a win32 platform you need also the gtk libraries. You can get them from:
ftp://lazarus.freepascal.org/lazarus/gtk-dlls.zip
or
http://user.sgic.fi/~tml/gimp/win32

Download the gtk+, glib, and extralibs DLLs from this site. Due to constant changes in
these files we do not maintain direct links to the files. Place the dlls in your \windows\system or \winnt\system32 dir

Marc

for the FPC is putting in interfaces? This is an essential feature for COM programming as well.

Another aspect of COM (or CORBA... another distributed architecture) is just how far do you want to make things cross platform compatible. On the Linux side of things COM supports is little bit of work in the WINE project, and one very proprietary COM platform that runs under Linux (with a cost of approximately $600 per "server" workstation.... not at all GPL'd) there aren't too many options. CORBA isn't that much better, but at least there is a GPL'd option for a CORBA orb.

The reason why COM is so important is that ActiveX, at least the current implementation by M$, is treated almost as a wrapper around a current COM interface. ActiveX controls are essentially a GUI interface to a COM object. Having spent the better part of the last two years doing nothing but writing COM servers and clients, I can tell you that it is an arcane art that takes some paradyme shifts in your thinking before actually implementing this stuff. There are some tremendous benefits to developing a large programming project in this manner, and it would be useful for it to be incorporated into Lazarus. I'm just suggesting that there is also quite a bit of underlying architecture that needs to be added as well.

BTW, much of the justification for implementing the registry in Windows in its current form was to handle many of the tasks required to deal with the OLE, COM, and ActiveX interfaces, and some of the discussions regarding the implementation of a Linux equivalent to the registry would be required as a foundation to any effort to develop a GPL'd COM platform. What I'm getting at is that putting in COM support into Lazarus is similar to helping design a really cool automobile, and then suddenly discovering that you also need to build the gas station, the oil refinery, and the oil derricks as well, not to mention the steel foundries, coal mines, ect. Now imagine that you are trying to get all of this going on another planet like Mars. As far as COM is concerned, Linux might as well be Mars.

Jeff.

BringToFront sets the last active window as the topmost window on the desktop above all other applications.

procedure BringToFront;

Description

Use BringToFront to find the window owned by the MainForm that was last active and bring it to the foreground. BringToFront also tests to see if the window is visible and enabled before making it the topmost window.

Vincent Snijders.

(last weekend I tried it the last time) the make makes no executables in the created tar.gz if I do a make linuxzip.

There is a problem in the editor options (Color), too. If I select the foreground color e.g. for the �reserved word� I get the colordialog and I can select the color and click on OK or CANCEL in the colordialog. This works OK, but if I now click on OK in the editor options the colordialog displays again. And if after many trys the OK works it could be that if I click in the lazarus menu the colordialog displays again. If this happen only a CTRL-C helps.

If this with the colordialog happands I get many of the following messages:
[GTKMotionNotify] Capture differs --> cap:0x8227740 gtk:0x08227740 [GTKMotionNotify] Capture differs --> cap:0x8227740 gtk:0x08227740 [GTKMotionNotify] Capture differs --> cap:0x8227740 gtk:0x08227740 [GTKMotionNotify] Capture differs --> cap:0x8227740 gtk:0x08227740 [GTKMotionNotify] Capture differs --> cap:0x8227740 gtk:0x08227740

cu Jens

which call subclasses. These subclasses then build a TFileStream instance and then call SaveToStream/LoadFromStream. Because of this there is No SaveTofile/LoadToFile at the subclass level. These levels include Tbitmap, TPicture and TGraphic.

I could be wrong, but I believe that internally they are stored as a bitmap, or possibly a dib.

Chris Bruner

are valid else you only can rely on the index value. Or it was the other way around. If all RGB values are 0 you have to use the index.

+ I committed some new code for TColorDialog. The selected
+ color can now be set.

OK

Marc

manuals. As I indicated in my mail to you they are located on the Free Pascal site. If you mean any kind of Lazarus docs., no.

functions are exported. I'm not very familiar GTK, but it seems that perhaps no target list to clear is being created (maybe GTK+/Win32 is using the native Win32 clipboard) so nothing negative would come from not calling this function in Windows. Of course, I'm probably wrong about this.

... 2. add some {IFDEF win32} to the gtk-interface code to use the windows

clipboard instead.

Would it be possible to use the Windows clipboard in GTK? It seems like it would be mandatory to use window handles and perhaps even a window procedure (if monitoring the clipboard is required).

Good luck to those who endeavor to make the gtk interface work on Windows.

>>>

THeader is a sectioned visual control that displays text and allows each section to be resized with the mouse.

Unit

ExtCtrls

Description

THeader is provided for backward compatibility. New applications should use THeaderControl instead.

>>>

Shane

fpc.cfg. That doesn't work. Only the LCL unit dirs are required. The LCL is build by issuing make lcl from c:\desarr~1\lazarus.

Marc

size argument.

---

as threadsafeness, dynamic arrays, variant support and other things such as porting to new platforms. PPC is already working, sparc should not be long.

Michael.

----------------------------------------------------------------------- It is still possible to link with libqtintf and either the Borland supplied libqt or an existing libqt version 2.3.x: In Delphi, this is controlled at runtime by defining the environment variable CLX_USE_LIBQT, and in C++ by compiling with a compiler define of the same name.
-----------------------------------------------------------------------

Michael.

You can use the _ _cdecl, _ _pascal, _ _fastcall, or _ _stdcall keywords to override the default calling convention on specific functions.

__cdecl is standard C call (where caller fixes up the stack) __pascal is pascal call (where callee fixes up the stack) __fastcall is where registers are used to pass parameters whenever possible, and callee fixes up the stack
__stdcall is where no underscores are generated, called function fixes up the stack.

Icon at 50,50.
DC of groupbox at 30,30

Suggestion:

hwnd := GetWindowFromDC(GroupboxDC)
P := Point(50, 50)
MapWindowPoints(Form.Handle, hwnd, @P, 1)

Now P should have the coords relative to the GroupBoxDC

Marc

the form resource data.

But, can you point me in the right direction of what to use?

I know how to find the resource itself and put it into a stream, I think.

After that I assume there's a routine that will convert that stream back to the text format that makes up the lfm file? From there it should be simple to parse...

Thanks,
Tony

TCmdLineDebugger.SendCmdLn "-stack-info-depth"
TCmdLineDebugger.SendCmdLn "-stack-list-arguments 1 7 7" TCmdLineDebugger.SendCmdLn "-stack-list-frames 7 7"

you can see that the IDE tries to find the source for the error, however it starts looking at entry 7 (why 7 and not start at 0 ?) and it stays there.
In normal situations the last entry on the callstack is application.run and there we can find sources for. In this case we don't have the source and my guess is that the IDE hangs on this.
Thats error one.

Why the exeption is raised the first place, i don't know. Don't have all sources here, but I guess again that GTKSTYLECHANGED is trying to release the nil PREVIOUS_STYLE

Marc

functions are the add ons, that are only used, if there is no LCL component to handle the task. In other words: The LCL wraps the interface in an object pascal way.

For example: The user should never use the LCLCheckMenuItem. For the user this is a low lvl function. The LCL delegates and controls the interface. So, the interface base is below the LCL.

Our trick is, that the actual implementations of the interface (gtk, win32) overrides the interface base. And because the user does not use the real interface, we have the choice to put it wherever we want in the hierachy. And the easiest position for the implementation is above the whole LCL and its base. That's why we can use TMenuItem in the win32 intf. This is only because of its hideous character. If we would use a perfect OO design, the implemented interface would ly right on the interface base and would not know the LCL.

The other side:
What would happen, if we put the LCL and the interface base on the same level?
This would mean, a call of LCLCheckMenuItem and the use of AMenuItem.Checked:=true is equivalent. This would mean the LCL logic must be handled in the interface (unchecking if it is a radio item, etc.). I strongly suggest, that we do not try this way.
So, my conclusion is, that the LCL should be clearly above the interface base.

That's exactly my point. Although it seems, you can draw different conclusions from it.

Back to the "unnecssary" casting:
- it is always a good idea to check the input of a function
- the interface functions can also be used by the user. Even if we say: Plz don't do. People will do.
- We can add function to TBaseMenuItem, so that te typecast is not needed.

Mattias

function Get16Bpg:Byte;
var
  c: DWord;
  hBM: HBITMAP;
  sDC,bDC: Windows.HDC;
begin
  sDC:=GetDC(0);
  bDC:=CreateCompatibleDC(sDC);
  hBM:=CreateCompatibleBitmap(sDC,1,1);
  SelectObject(bDC,hBM);
  SetPixel(bDC,0,0,RGB(0,100,0));
  c:=GetPixel(bDC,0,0);
  DeleteDC(bDC);
  DeleteObject(hBM);
  ReleaseDC(0,sDC);
  if GetGValue(c)>=100 then Result:=6 else Result:=5;
end;