Sorry by my English I speak Spanish.
I have an app in Ms Access 64 bits. My goal is to store a serialized collection of objects in a field of a table. For this I am using a function published in VB Helper http://www.vb-helper.com/howto_vb6_serialize.html, for which I must have access to tlbinf32.
Well, this dll is 32 bit but thanks to #Simon Mourier's answer tlbinf32.dll in a 64bits .Net application it can be added as COM+ Application for use in 64 bits applications. This has been going great, but how do I reference it in a vba module using Tools -> References?
Thanks in advance
Eduardo
Related
My application is developed in Delphi 6, The application have some document management modules which works fine with 32 bit MS word, but not with 64 bit MS Word.
A type library called WORD_TLB is used to access the MS word functions from delphi code. Can i generate a new type library or something else to make the application work with 64 bit MS word? Is it even possible for a Delphi 6 application to work with MS WORD 64 bit?
Please suggest.
Is it even possible for a Delphi 6 application to work with MS WORD 64 bit?
Yes, it is possible to automate 64 bit Office applications from a 32 bit Delphi process. The Office applications execute as out of process COM servers and so the mismatch of bitness is not an issue.
I'm sure that you do have a problem, but that problem is not due to trying to automate 64 bit out of process COM servers from a 32 bit process.
I've been searching for some information regarding microcontroller programming but the info I find is either way over my head or doesn't appear to exist. I'm looking for something easier to digest! I'm relatively new to programming and come from an SQL DBA background and decided that it would be quicker for me to learn some programming fundamentals and then teach myself Delphi than it would to get some changes implemented through my company's insane design change note system!
After a couple of years of Delphi programming I can cope with writing database applications without too much bother and I want to be able to move on a level.
We use PIC microcontrollers on our PCBs; mainly the PIC18F family. The software on the PICS is written in C but there are parameters values that are written to by a Delphi application that interface with the PIC using an ActiveX control.
Basically, SQL Database holds parameter info, Delphi client app retrieves those values, passes them to the ActiveX controll which does all the low level stuff on the PIC. For example the internal EEPROM will have a map and within any particular address a value will be stored to switch something on or off or hold an integer value etc.
I've gotten hold of an MPLAB kit which has an ICD2 device that can read and write values to the internal EEPROM and I understand how to change these hexadecimal values using MPLAB software.
My hope isn't to learn embedded microcontroller programming; rather that I can write a Delphi app that will do something similar to MPLAB software. E.g read and write values to certain memory addresses within the EEPROM.
I'd be very gratefull if anyone can point me in the right direction of any libraries or components that may already exist for bridging this gap between simple Delphi form application and writing low level PIC EEPROM. I doubt such any easy interface exists but I thought I'd ask. To summarise I want to be able to have a simple form app, with some edit boxes that the user types in or selects from dropdown boxes, parameter values, to click on a button and to assign those parameter values to specific EEPROM memory addresses. Thank you for reading and any comments would be gratefully received.
Regards
KD
I'm a big fan of MikroElectronika and have used their Pascal tools for pic16 series MCU with great success (touch screen interfaces, ZigBee, ...).
http://www.mikroe.com/
Updated 2015 Answer:
Why not a Raspberry Pi with FreePascal and Lazarus? The boards cost from $5 to $25 US, as of this date, and the development tools are free.
Original 2012 Answer:
If you like to use Pascal, you might find Free Pascal useful on small embedded systems, but the minimum I believe you will find it can compile on is a Linux-based ARM embedded system. The fact that you use pascal on both sides is very unlikely to help you accomplish anything major.
If you want to go all the way down the the smallest PIC microcontrollers, you'll find that it's almost always a variant of C that you'll be using. Frankly, at that level, the differences aren't that much. If you can write Pascal, you can learn enough C in a day, to use with microcontrollers.
Don't be scared to use the native language that most microcontrollers support. My personal favorites are the Rabbit microcontrollers, formerly from Z-World, now from digi -- I think I paid about $100 US for the first board and development toolkit.
Interfacing such an application with delphi is pretty easy, usually these days, I would interface using TCP/IP over either wired Ethernet, or wireless (Wifi). But if you really want to you could use RS-232 or RS-485 serial links. (RS-485 has the advantage that you can wire it up to 5 miles long.) If I was using a serial link, I'd probably implement something like Modbus on both sides, if I just wanted to send some numeric data back and forth, and if I was doing something text-oriented, I think I'd write a mini HTTP web server on the embedded controller, and most boards these days come with enough HTTP server demos to make that drop-dead easy.
Delphi outputs Win32 and Win64 native applications you can write software that can interact with certain devices if the PCB has serial comunication or I2C you can write software that in Delphi that it will interact with the physical device.
But if you want to programm the devices yourself , write software that will run on this devices you can't do it in Delphi. I suggest you buy an Arduino it's an excellent envoirment for beginners in microcontroller programming.
If you have the source code of your pic microcontroller then you can implement the code in C to read from Serial, USB or some other interface available in your hardware and write it to the eeprom. This way its easy to write the app in any high level language like delphi, c++, etc.
Or you can write your PIC application using the mikropascal compiler from mikroeletronika that its very good and I've been using for a long time, but as you can see you will have to implement some mecanism to read from the interface and write to your eeprom as I've mentioned before.
This compiler comes with a lote of librarys to work with many devices. You should take a look on it, its not free but the price is low and in their site you can find samples and sample boards to test it.
One option, if you want a simple interface to write to the PIC EEPROM, is to use the ICD command line utility. Unfortunately it is not available for the ICD2, but the PICkit 2 and 3 (which are cheap), ICD3, and RealICE have command line utilities that give you the ability to write to the EEPROM (google pk2cmd). In Delphi, you could just wrap a very simple set of command line calls to pk2cmd.
I am busy with a project where I have to code a program in Delphi that will translate an English word to another language. What would be the easiest way to approach this? I was thinking about using Microsoft Translator V2 API from Delphi, but it seems very complicated and I am not yet that experienced in Delphi. Any other suggestions?
Thanks in advance :)
Thanks to RRUZ you can follow this article about Microsoft Translator V2 API implementation for Delphi; inluding the full (even speaking) example.
If you don't have to be self-contained, you could make a webservice call (soap, etc..) to the cloud (google, etc..). The nature of your app (is it a translation program? or do you just want to provide translation in another app, along with spellcheck, thesaurus, syntax highlight, etc..?) will determine whether this is feasible or not.
I have an object that uses more than 2 gigabytes of virtual memory
But Delphi only managers 2 GB
I'm considering ether making a number of objects and grouping them and using the windows wow64 method some how and use 64 bit windows.
Or just upgrading memory manager to 4 GB and build it around Int64.
effectively I need TStream as the base object with Int64 used, instead of integers.
Lexdean, you're saying:
effectively I need TStream as the base object with Int64 used, instead of integers
Well then, you're in luck (twice) because:
Delphi's TStream uses Int64 for position, it can access files much larger then 4Gb.
If a TStream interface is enough, you can write your own TStream to do whatever you want, you don't need to wait for an native 64bit Delphi compiler.
But if I were to answer the question in the title:
How to write a memory manager that maps 4 giggs for Delphi
There's no way to do that with an 32bit compiler. Join the crowd of people asking for an 64 bit Delphi compiler!
Having a single 2 gigabyte object is not a good idea. If memory is fragmented you won't be able to allocate one even if the amount of free memory is enough. I would suggest that you try to use a list of smaller objects.
(I remember how in Turbo Pascal (the predecessor to Delphi) a variable couldn't be larger than 64 kilobyte... Oh, the times... ;)
Unfortunately there's no Delphi compiler as of yet that compiles 64-bit code. You can get more out of your 32-bit address space if you put {$SetPeFlags IMAGE_FILE_LARGE_ADDRESS_AWARE} in the DPR, though. It sets a flag in the PE header that lets Windows know it can allocate more than 2 GB of virtual memory to it.
Guffa's right, though. If your object is trying to grab 2GB+ of contiguous memory, you're probably doing something wrong. What are you trying to do? Maybe there's a simpler way...
You can use AWE APIs to obtain access to more memory in win32 apps. But you have to think your code around AWE rather than adapt AWE usage for your code. What I mean is that you can write a TAWEMemoryStream ... but it is not a good idea.
I'm working with a team for a bigger application with Delphi 2007. It use a bigger legacy framework to access the data. Both the app and framework use String as datatype for strings. I have started to modify the code in framework to support Delphi 2009 strings, see my previous questions about this.
I see 2 alternatives now:
Alt 1 - Continue to use string as before. This is probably the cleanest solution as the framework will then supports Unicode. But the code in framework must be modified a lot to make this working. This require in depth understanding of the internal algorithms in framework. It is also a bigger chance to introduce new bugs.
Alt 2 - Replace String with AnsiString and Char with AnsiChar. This is propably a much easier solution and also how I start to modify the code (but then I start thinking and ask this question...). The negative side of this is no support for Unicode. Unicode support is not a requirement as it worked before but is nice to have. It could also be useful in the future. Another problem is that the application must send Ansistring variables as parameters in the methods for the framework instead of String as before. There are thousands of calls to change...
So I don't know right now. Both options require a lot of work, but Alt 1 is probably more risky and time consuming. What I want from this forum is feedback and comments as I guess I am not the first who have this problem.
EDIT
Another issue is the memory footprint. I wrote a quick test that allocate an array of one million strings. Each string was filled with 26 chars from A to Z.
With Delphi 2007 it took 40.011.600 bytes and the time was 4:15 minutes.
With Delphi 2009 it took 72.015.580 bytes and the time was 4:45 minutes.
The memory consumption was measured with GetHeapStatus.TotalAllocated.
I don't think we can afford to have the strings allocate twice as much memory.
It is not unusual to have 500 MB in memory consumption for each client now. I guess much of this are as strings. Propably we try to use AnsiString as much as possible.
Regards
Either stay with the old version of Delphi, or go all the way. You'll have to sooner and later anyway.
Note that the "replace everything with ansistring" scheme is also not entirely foolproof, specially if you touch streams and your fileformats need to stay the same. There are no explicite TStringlists,tstringstreams etc with ansistring anymore.
The same probably goes for Datasnap, Indy and other frameworks.
You can try to use this trick for certain string intensive parts at first, to avoid changing too much code directly. E.g. I had an own XML library, which I patched to remain mostly ansistring. The library was only used sideways, and unicode was of no importance to it.
Start with "alt 2", then gradually add unicode support to your framework, then move over to Unicode.
Rationale: you want a stable app; switching over to Delphi 2009+ will eventually require you to really support Unicode.
Edit: 20100125
While doing "alt 2" watch the Delphi compiler hints warnings.
The situation that Andreas describes will generate such hints and warnings.
I have explained this in my CodeRage 4 session about Unicode and other encodings.
The above link points to a page where you can view the replay of that session.
If you still have questions, just drop them here.
--jeroen
We evaluated the transition 2007 -> 2009 a year ago and tried a a smaller project (200k lines). The result was that everywhere where you do not use "fancy" things like pointers, set of char etc the porting is really not that difficult . Especially the GUI units we're ported within a day or so. This is equivalent to opt1.
The library units with low level routines, access to measurement systems etc etc was a whole different story. Here we choose to translate string -> ansistring, char -> ansichar etc etc. Porting these units is a pain to get correct and the customer won't pay for the transition. Hence opt2 for those units.
This mixed method gave us best of both worlds but we will keep some larger projects at Delphi 2007 and probably only port when a 64 bit version of the compiler will come out.
It'll be more work, but I'd really recommend that you upgrade to Unicode strings, because that's the native string type of the VCL and so all your controls will be dealing with Unicode strings anyway. Trying to convert everything back and forth will cause you all sorts of hassles.