You should be very careful with external connections: SCOOP does not automatically protect against double-release of external resources by objects that were obtained by cloning them. So, it’s OK to clone and serialize user objects. But I’d rather avoid doing it with objects used to access

Serialization is rather a heavy-weight solution. I’d stick to creation procedures that accept a separate argument. For more complex cases (including the one used in the initial question), serialization can also be avoided by using a visitor pattern. Alexander Kogtenkov Gachoud Philippe

You can find some simple examples at https://www.eiffel.org/doc/solutions/Persistence%2C_storage%2C_and_retrieval#With_the_SED_persistence_format They use a file, but it should be possible to do everything in memory as soon as functionality of IO_MEDIUM is implemented with some other storage

As a third solution for other cases, would you recommend the make_from_separate feature in all classes when they are not deferred, and serialize when they are, or would you recommend serialization for all? many thx On Tuesday, June 2, 2020 at 3:53:57 AM UTC-4, Alexander Kogtenkov wrote: > > I

Hi Alexander, many thx for your answer, the option 1 would for me simply report the problem for me which is in many of my cases having a parallel part (separate) and a synchronized part (non separate). The problems for me don't occur so much in creating a new separate but on returning into a

I can see two possibilities. Which one is suitable (if any) depends on the application. 1. Change the type of attribute `mother` to be separate. Then every object of type CAT can be separate, but all they share the same `mother` object. This would require additional synchronization when

I'm on a way of trying to get a separate DB_CONNECTION with ODBC. And its really difficult for me to realize that base_selection has to have some make_from_separate methods, as much as the cursor to access the data, as much as base_update, none of these classes seem to be prepared for SCOOP or

Hello everybody, still scooping I'm struggling with following problem, hope its self explanatory otherwise I explain it above: deferred class FEMALE end - - class FEMALE class CAT feature {NONE} -- Initialize make_from_separate (other: separate like Current) do

This new release of Gobo Eiffel should work fine with EiffelStudio 19.05 and 19.12. Please see the release notes here: https://github.com/gobo-eiffel/gobo/blob/master/History.md You can download the Gobo package from SourceForge: https://sourceforge.net/projects/gobo-eiffel/files/gobo

I just rediscovered a routine EV_SCREEN.monitor_area_from_window (a_window: EV_WINDOW): EV_RECTANGLE which my code was already calling. Doesn't work however. Investigating... On Friday, 29 May 2020 21:52:25 UTC+1, Alexander Kogtenkov wrote: > > I’m not an expert in Vision library, but given that

Hi Alexander, well let's be a bit more abstract about the problem. I have an application that started up with some 'reasonable' outer window dimensions. Ideally it would be on a single physical monitor (i.e. not crossing the boundary over two monitors). Now I just want to make sure that a dialog

Hi Javier, With Jocelyn's help, I have managed to reinstate my access to support.eiffel.com and have reported this as a bug. Regards, Howard On Sunday, 24 May 2020 09:51:30 UTC+1, howard.thomson wrote: > > Hi, > > I am currently developing a dialog for my current project, inheriting from >

I’m not an expert in Vision library, but given that it’s unclear what "current screen" means for a window that can be shown at two or more physical monitors at the same time, would the following work? 1. Send a message to maximize current window (or a child window; maybe, even invisible

I'm coming back to some code after a few years. Peter Gummer and I wrote a lot of wrapping code for EV_GRID, and one of the things we never managed to do was make it so that dialogs containing grids had proper size and resize behaviour, no matter how large or small the content might be. A basic

Hi Howard, On Sunday, May 24, 2020 at 5:51:30 AM UTC-3, howard.thomson wrote: > > Hi, > > I am currently developing a dialog for my current project, inheriting from > EV_DIALOG and using EV_FIXED to place widgets. > > I started out using EV_FIXED.extend_with_position_and_size, but ended up > with

Hi, An issue that is bugging me, is that the EiffelStudio editor does not always distinguish between typing text into the content of a quoted string, and typing code with the attendant auto-expansion of keyword introduced structures. I have just typed the word 'from' into a section after the

As of now, other possible solutions include {ARRAY [NATURAL_32]} <<0x2, 0xC, 0xF0, 0xFF00, 0xFFFF0000>> {ARRAY [NATURAL_32_REF]} <<{NATURAL_32} 0x2, {NATURAL_32} 0xC, {NATURAL_32} 0xF0, {NATURAL_32} 0xFF00, {NATURAL_32} 0xFFFF0000>> Alexander Kogtenkov jjj :

Result := {ARRAY [like Current]} <<0x2, 0xC, 0xF0, 0xFF00, 0xFFFF0000>> where Current is a NATURAL_32_REF, will not compile. The compiler says, VWMA error, non-conforming manifest array. Manifest array element at index 1 has type INTEGER_32 incompatible with declared element type like Current.

The class to demonstrate the failings: note description: "Summary description for {DEMO_DIALOG}." author: "Howard Thomson" date: "25-May-2020" faults_to_fix: "[ The EV_DIALOG routines set_item_position_and_size and extend_with_position_and_size fail, accoring to the subsequent 'check' assertions.

I wanted to study the issue of CAT calls ( https://www.eiffel.org/doc/eiffel/ET-_Inheritance#Catcalls) I then created a new project (a simple console application) in Eiffel 18.11 and just changed in the project settings the target option for "capability" of catcalls from "void" to "complete". If

Revisiting the point about the order of clauses: I am no longer sure what the fuss was about since this is a case in which we *did* ensure backward compatibility. You can use the old order (variant clause immediately after the invariant) as well as the new one. If you used the old order you will

Hi, I am currently developing a dialog for my current project, inheriting from EV_DIALOG and using EV_FIXED to place widgets. I started out using EV_FIXED.extend_with_position_and_size, but ended up with no widgets visible ! EV_DIALOG.extend followed by EV_DIALOG.set_position works, and shows

Hi Anders, To some extent your interpretation is correct. However, there are some nuances: 1. If the separate argument is not used or is used only as a source of reattachment (i.e. there are no calls on the argument), it may be not blocked at all. 2. If the separate argument is

Hi Have I understood it correct that as soon as I have a separate object as i parameter to a feature I grab that resource and it is not releases until I leave the feature? Something like this: separate_string : separate STRING ... ... ... separate_string is not blocked my_feature( separate_

Hi I am running a SCOOP application and I try to understand why on SCOOP process is not able to make a call to a separate object. Probably due to that that object is grabbed by another SCOOP process. In the debugger I can see some of the SCOOP processes. But I have a problem with that the I can