|
Vaclav_Sal wrote: Now since the processor I am using is 32 bits processor how should I organize the bits array - 8 bits wide or 32 bits wide or does it matter as long as I process it correctly?
Doesn't really matter... the only thing that really matters is that it rests on an 8bit boundary, because computers can handle that more efficiently than anything else (since RAM is allocated on 8bit boundaries).
edit: What I mean by resting on an 8bit boundary means that if the sample resolution you're dealing with is one bit (or three bits) you'd still want to pack that to 8bits (fill the non-used bits even though you're not using them).
|
|
|
|
|
I would suggest that you make it 100 bits wide, rounded to the nearest 32 (i.e. 4 words). That will ensure that each row is aligned on a 32-bit boundary which is most efficient for this architecture.
|
|
|
|
|
Well, if you have to access each bit independently (i.e. sample-wise), bit packing is still way more efficient than doing block-wise packing.
|
|
|
|
|
Sorry, not sure what that means in relation to my suggestion.
|
|
|
|
|
Hi to all,
for my projects, sometimes i have to communicate with another computer, sometimes using serial port, sometimes using ethernet and so on: i had write some classes to use for this communication.
Last time, on july of this year, my "communication partner" ask me to give him my class to be sure we use the some method, but i work with VC++ and MFC and he works with old visual basic; from this question, there is a way to make a DLL for each class i have, which is used by old visual basic, VC++ (with this, i think there is no problem), C# and Delphi (these are the most used languages in my neighborhood) ? I have to re-write all classes removing the MFC functions, or it's possible leave them so ?
Thanks
|
|
|
|
|
DRUGODRF,
This is a great question. My initial thinking is that this is exactly the kind of situation that COM was developed for.
However, if you already have working DLLs that are adequate for your purposes, then re-writing the Communication components in COM, would be extremely time consuming.
I think the answer to your question depends on the output of the compiler used for whatever language employed, and the complexity (and compatibility of the type systems) of the communication class that you have designed.
My coding experience is mainly C++ and Assembly language,...and, so, I have no idea how a Visual Basic compiler would implement your component. But, I think that if the dependent libraries for your component exist on both computers, then it doesn't really matter if you use MFC or not,...the code execution will jump to the location address specified in the import table of your DLL for the invoked function.
But, the primary concern here is: just how reliable is this way of remote communication ???
modified 6-Nov-14 15:54pm.
|
|
|
|
|
You have two alternatives, using COM or a C interface. Which one suits you best depends on what sort of data and parameters you have, and how complex your interface is.
Putting a C interface on your classes means that you don't export any C++ classes or functions, and use no MFC or C++ classes in your interface. This tend to require a bit more work on the side of the user of the functions. For instance, instead of creating an instance of a class and call functions on that, you would call a free function that creates one internally, and gives you a handle to it. You then use that handle in subsequent function calls (in MFC, all CWnd classes wraps a HWND handle - for this you'd do the opposite).
If you want to keep the class interactions, you have do duplicate them in COM. Keep the classes you have, but wrap them in COM class interfaces. This tends to be more work for the library writer, as you have to create and register interfaces and do marshalling and type conversions, but it will let VB, C# and Delphi to work with the COM classes rather than a C function interface.
Both methods work for VB, C# and Delphi - it's just a matter of choosing where the pain is. 
|
|
|
|
|
The interface are very simple, but are all C++ classes and i use MFC functions and classes.
I take a look to all proposed solutions.
Thanks to all very much.
|
|
|
|
|
plz post or reply through a code solving patience sort as soon as possible
|
|
|
|
|
|
link[^]
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
|
|
|
|
|
|
pretty please? 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Sorry, I just don't have the patience.
|
|
|
|
|
|
Is there a way to hide/show, enable/disable a "child" window with IAccessible ?
I can only get some values (::get_accState(), STATE_SYSTEM_INVISIBLE, ...) but cannot set them
It is for a "QWidget" window class, where all the childs that I enumerate (AccessibleObjectFromWindow(), AccessibleChildren()and so on) have of course no window handle (the same as the parent in fact) and I cannot use standard apis like EnableWindow() or ShowWindow()
|
|
|
|
|
Castorix wrote: It is for a "QWidget" window class
I'd imagine you'd want to search the Qt documentation for how to do this.
Castorix wrote: I cannot use standard apis like EnableWindow() or ShowWindow()
Typically these API's are built over the Windows messaging system, so even though you can't access the calls directly, you can actually still send the message to the Window. If Qt isn't intercepting or doing anything weird with those messages, they may still work (although I'm not sure if the Qt framework still uses regular Windows APIs underneath the hood to make windows when working within the Windows environment).
|
|
|
|
|
There is only one real window ("QWidget" class which allows me to use AccessibleObjectFromWindow()) but all childs are not windows, so I cannot send win32 messages.
I can enumerate them and read their properties (exactly like AccExplorer32 does), but I did not find a way to change them as I cannot interact directly with them using Win32 messages/apis
|
|
|
|
|
Castorix wrote: There is only one real window ("QWidget" class which allows me to use AccessibleObjectFromWindow()) but all childs are not windows, so I cannot send win32 messages.
Actually... this depends on the Qt implementation, they might be windows. In MFC, all childs are windows (to some extent, most are derived from the same classes), so you can message any of them.
Castorix wrote: I can enumerate them and read their properties (exactly like AccExplorer32 does), but I did not find a way to change them as I cannot interact directly with them using Win32 messages/apis
Again, this depends on Qt implementation... but you can send windows messages to ANYTHING that's a window in MS Windows. If within Qt, they simply wrapped the MS lower level APIs, then you can access those windows directly by messaging them.
By the way, not because you can do it does it mean you should.
|
|
|
|
|
No, I'm talking about a real case where there is a "QWidget" main window and NO real child windows (I can check with Spy++), so I know I cannot send win32 messages and I cannot use Win32 apis on them, because they are not Win32 windows.
I did all the code to enumerate pseudo-childs with IAccessible interface and get their properties/states
I just wanted to find a way to enable/disable one of these pseudo-windows (a pseudo-button (not a Win32 "Button" class), with no window handle)
but it seems impossible.
|
|
|
|
|
I would assume Qt has methods for all of this... have you checked out their documentation? Although from my own personal experience... I know their documentation isn't very good.
|
|
|
|
|
Our application develped in C# uses a dll and static library(lib).
The dll is intermediate project for static libraty and C# application.
Client has provided files(library file and a dll) which is required for interacting with their application.
1. In our C++ static library we are using only the library file provided by client by statically linking it.
2. Our C++ wrapper dll references this C++ static library created in step 1.
3. C# application references the wrapper dll created in step 2.
Since the library file is statically linked in our C++ static library, does the dll also need to be linked/referred in our application.
|
|
|
|
|
its not clear how the c# application (3) is using the c++ wrapper (2)
if you're using p/invoke, then the 'reference/link' is in the p/invoke statements themselves, ie, the DllImport clause
|
|
|
|
|
If the C++ dll has been linked to the static library, then you only need access to that dll in your C# code (assuming I have understood the question correctly).
|
|
|
|
|
Member 11201788 wrote: Since the library file is statically linked in our C++ static library, does the dll also need to be linked/referred in our application.
Do you mean dll or lib at this point?
If you mean lib, then it should be a no, you don't need a reference to it while building your C# application. If you mean dll, then yes, your C# application does need a reference to your dll.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
