Eh? I can’t really make the reproduction steps any more concise. They are two brand new projects with different names, Xojo creates them with different binary names (test1.exe and test2.exe) at the outset so there should be no clash, just like there’s no clash on Mac but they do clash on Windows.
This is a terrible bug which means I can’t debug test Xojo web<>desktop integration correctly without using different Xojo versions on windows. This makes it literally impossible to test if you need features from a certain version of a Xojo release. Why don’t I just run the desktop project before the web project as that works, well this means I can’t debug both projects with the web project in a running state while the desktop app is launched.
I’m putting this here as I can’t type all this into a single line text box in feedback on the off chance that the ticket is re-opened, I don’t even know if re-open requests are looked at as I’ve been asked in the past to make a new ticket and I have other re-open requests sitting in feedback with no response.
Xojo, how do I debug a web project and a desktop project at the same time using the new features of 2019r1.1 in Windows without resorting to two machines or a VM because I’d hope you’d tested that before mentioning it as a resolution step in the closed ticket, or is that a guess?
This is the error i get running first the webapp and then start a desktop program. For many years it wasn’t possible to run more than one desktopprogram on Windows. At one point Xojo made a change to support multi desktop programs run simultaniously but forgot to change it in webprograms
I just checked this. When you follow the instructions on the case:
[quote]1) Create a new web project called test1
2) Create a new desktop project called test2
3) Run the web project then run the desktop project and notice that the desktop project doesn’t run, it sits at the progress bar for a while then the IDE looks like its in a running state but the app is nowhere to be seen.[/quote]
When I read these steps, I created two projects and saved them as test1 and test2, but did not change the executable names.
This is part of the reason that example projects and exact replication steps are so important. I have reopened the case based on this new information.
One of the problems with this is that the interpretation of a second person doesn’t always match what the original person actually meant. This is part of the reason why I prefer to get the example projects from the original case author rather than from one of our testers.
“Robin Lauryssen-MitchellMay 2, 2019 - 1:22pm UTC This issue has been reproduced based on the information provided.”
There was no mention of saving the project in my steps. Saving projects hasn’t got anything to do with creating new projects. Simply create a new project with specific names. File>New>tap tap tap. I didn’t need to include the step of ensuring that the windows app names were different as I knew that if you create a project called test1 it sets the windows app name to test1.exe and likewise for test2 called test2.exe so there was no chance of an executable name clash.
I’m not here to hand hold you though the minutia of your own product. I laid out the steps and you seemingly didn’t follow them and added some more steps of your own. You then also seemingly didn’t bother to use your own staffs example projects that clearly showed the problems. I’m sorry Robin, it seems Greg would rather do his own interpretive testing than use the projects you provide, I’m not sure how that goes for the other engineers.
As I mentioned above, I’ll revert to including a video in the future so I don’t have to spend time writing down each character you need to type into which box after selecting then with which finger of your hand on which mouse button…
But your closing comment on the ticket says:
That clearly doesn’t work, if you had done that test you’d have noticed the problem, so was that a guess?