Attila Kovacs

Just for curiosity, why don't you just copy the 4 files into the output folder manually and move on?

CardForm := TCardForm.Create(Self)

great! you can remove that comment in the middle 🙂

@aehimself great work, nice catch. would you make a QC report?

hehe, suddenly, the results of "UnpackDDElParam" make sense 😉 so looks like it can be done without it and without FreeDDElParam and without the reimport edit: almost The lParam parameter of the posted DDE message that was received. The application must free the memory object specified by the lParam parameter by calling the FreeDDElParam function. -

pLo, pHi: UIntPtr; .. if UnpackDDElParam(AMsg.msg, AMsg.lParam, @pLo, @pHi) then .. GlobalUnlock(pHi); GlobalFree(pHi);

PeekMessage "Dispatches incoming nonqueued messages, checks the thread message queue for a posted message, and retrieves the message (if any exist)." "During this call, the system dispatches (DispatchMessage) pending, nonqueued messages, that is, messages sent to windows owned by the calling thread using the SendMessage, SendMessageCallback, SendMessageTimeout, or SendNotifyMessage function. Then the first queued message that matches the specified filter is retrieved." ok, that means, it should be fine

first of all, PeekMessage is blocking, therefor the repeat until is not just superfluous but could be a problem, do you know where exactly the AV happens? sorry, that was getmessage, the blocking one. well, then I don't think I can comment on that

Try to find some resources on "relational database" first. Instead of stuffing everything into a giant BLOB in one record, split them up in other tables in many rows and have a reference to the main document.

I'm not sure on that. Look the code in Berlin, it's searching from the left and returning the first matching element. Edit: oh no, I see. Edit edit, well, no-oh no, can't see again. 😄 If the list is sorted I can't create a list where binsearch would not return the first element in the list. Berlin U2.

Why did they change it in the first place?

you need one, a window handle too

Eventually I got rid of ackMode. I should really stop it now. 😄 uBdsLauncher2.pas

There is no such thing as a central DDE server or anything, the DDE lib sends a message to every enumerated main window a WM_DDE_INITIALIZE with Service and Topic and the application will either answer with a WM_DDE_ACK or not. That said, on 16349, or if the list is zero, you have to start bds.exe /np filename.pas. That is what's in the registry for bdsLauncher.

of course, if no IDE is running there is no DDE to answer the requests

Ok, I just tested this on 4 different pc's under 3 different os's and 3 different IDE's, no errors or lockups. (Could still contain bugs) I'll just leave it there for now, if someone has a better implementation just share with us. uBdsLauncher2.pas

Well, the whole ackINIT / ackEXEC thing is just a crap because I have no idea who sent the ACK.... also, there is difference between posted and sent messages, which I also cant distinguish. The whole DDE fuck is just some botching from MS. I'm sure they can't even document it as they don't know why is it working. So it's possible that I get an ACK message and I wan't to free the globals from it's parameters, but it was not an ACK for the EXEC, so AV on nil handle raises. You could try to check the return value of "UnpackDDElParam" and only free the globals if it's != 0. if UnpackDDElParam(AMsg.Msg, AMsg.lParam, @pLo, @pHi) <> False then begin GlobalUnlock(pHi); GlobalFree(pHi); FreeDDElParam(AMsg.Msg, AMsg.lParam); end; this would eventually solve the AV but not the problem

The ackINIT was for the other version, (see attachment), I just left it there, you can put (FAckMode := ackINIT;) into the initialization, instead. (It won't affect anything though) Double-check your implementation, both versions are stable on my PC. The problem was calling GlobalUnlock(ddeCommandH) and GlobalFree(ddeCommandH) right after WM_DDE_EXECUTE. If you are still getting the 16394, I suspect, you still have this in the code. uBdsLauncher2.pas

Sorry, got a little intermezzo, I broke my IDE had to debug it to make it work again.... Well, here is the thing, user32 version with ~proper ACK handling, seems to work. Could you check it? (It's still just ~proper as the command global won't be released if there is no ACK. But I would implement it only if it became stable.) uBdsLauncher2.pas

Don't. It's Postmessage on purpose. Wait until I make the changes.

"When processing the WM_DDE_ACK message that the server posts in reply to a WM_DDE_EXECUTE message, the client application must delete the object returned by the WM_DDE_ACK message." This could cause that eventually, freeing up that global right after the execute instead of waiting for the ACK. This could also be the problem for the user32 version.

No way, this was the first thing I tried, 2 days ago. Nothing changed..

What do you mean it interfered with sending commands? Can you be more specific? I have this error handling and you will get error 16394 after the 4th call. (Again, look into the DDE logs)

There is an array with the window handles which answered to DDE_INITIATE, there is GetWindowExeName to get the executable, you have everything just like before, the only difference to your needs is, that I'm trying to open a file in every running IDE's in my demos.

by the way, if you are looking into my logs, DdeConnectList does the same. The only thing I don't know, how "DdeConnectList" is enumerating the windows. It was sending it to 128 ones.