|
This is the C++ forum please try elsewhere.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Looking at the documentation xlSheetVisible property
Assembly: Microsoft.Office.Tools.Excel (in microsoft.office.tools.excel.dll)
does this mean this property is exposed in excel.dll if so I only have the executable
thanks
|
|
|
|
|
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I am thinking I have to have some dll where this
Method is exposed
|
|
|
|
|
Yes, and you already showed that information in your original question; it is part of the Office interop. However, you need Microsoft Office installed on your system in order to access it. What exactly are you trying to do, and is this really a C++ question?
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
OLE programming and since at work I cannt down load anything I want I am guessing what I am looking for is in nativeexcel.dll
The only thing I have on my machine is excel.exe
|
|
|
|
|
ForNow wrote: The only thing I have on my machine is excel.exe Then you should have the required DLL's also. Have a look here[^] for some suggestions.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Hi ALL!
VC++6.0, XP SP3, MFC Dialog-based App.
Adding a next item to the menu I've suddenly got a message "Out of memory. Unable to complete command". After restart it's impossible to load project clicking .DSW file: workspace stays empty, no files loaded.
Killing of the .CLW solves the problem for an one session. After I restart project, it again doesn't work, need delete .CLW again.
Now, I cannot add a menu item. Currently there are about 1000 items in the menu. I have a bad suspicion that may be there is a LIMIT for the wizard when it adds a menu item?
Please, any ideas how to add items?
|
|
|
|
|
Member 708172 wrote: Currently there are about 1000 items in the menu. Seriously? How do you expect anyone to navigate such a maze? You should rethink your design.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
There's really no reason why you should have that many items in a menu. You're at a point where no person would want to navigate through that.
|
|
|
|
|
Member 708172 wrote: Currently there are about 1000 items in the menu.
VS, every user of your program, the universe and life itslef probably hates you for that.
|
|
|
|
|
I have no questions about design. I have questions about fight the wizard in VC6.0
-------------------------------------
PS. This project isn't bubbleshooter or a text processor. Therefore its menu doesn't consist of Help->About only.
This project operates with cars, that are splitted by models. Do you know how many car models in the world?
No, you don't, but somehow you are sure that our users are not happy to navigate through this menu.
Who from you solved a problem to combine over 1000 cars in an one project? Nobody. But all seems that they are guru in this question... OK, I'm listening you, make your suggestions...
|
|
|
|
|
Well, don't put every single model into the menu but just the highest hierarchy level. Open a sub dialog with a ComboBox (or several if there are more sub levels) and add only the items apllicable for the current parent level. This should cut down your memory usage.
|
|
|
|
|
A suggestion: Rethink your design.
I (and probably all others here) would use a database and provide filter options to query matching recordsets and show the results as list from where additional actions can be executed. Doing so allows you to update the database with new data without changing a single line of code for your application and you will not run into any limits.
A probable solution is using dynamically item creation rather than using resources. When doing so, you may realize that using a database is a good idea. Finally, switching from menu selections to lists with filters may also come into mind.
|
|
|
|
|
Member 708172 wrote: I have no questions about design. I have questions about fight the wizard in VC6.0 If you design it correctly you will not have to fight the wizard. This is not a good way to deal with large numbers of options, as others have pointed out. You should consider the use of dialogs with lists which will allow you to alter things dynamically rather than having to rebuild your entire program every time a minor change in your item set occurs.
Member 708172 wrote: Who from you solved a problem to combine over 1000 cars in an one project? Nobody. You have no idea what problems some of the contributors here have solved; many have been working very successfully in IT development for years. That is why you should listen to their advice. Of course you are free to ignore it and stick with your own design, but don't be surprised if you run into even more problems.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Are you really using menus (i.e. CMenu, ... ) ??? or are you talking about something else ?
If using menus, split the menus into sub menus of companies and models; that will probably help.
IMO, menus are not designed to do this kind of interaction.
My suggestion would be to have (at least) 2 list box side-by-side, first one on the left would be the car manufacturer, and the one on the right would be the car models which is dependent on the manufacturer.
Scenario :
- first list is filled with car manufacturer; second list is empty.
- user selects car manufacturer; second list is filled with car models.
- user selects car model on the second list.
You can also add some more UI to select the car manufacture year.
You can also add behaviour so that the user could start type the car manufacturer and/or model to automatically scroll to the appropriate item in the list.
...
Good luck.
Nihil obstat
|
|
|
|
|
>Are you really using menus (i.e. CMenu, ... ) ???
Very good question. I do not use CMenu, instead I did Insert->Resource->Menu and wrote menu items. Next I involved the "dialog properties" and selected this menu in a listbox.
I didn't use directly CMenu.
About csenario: "...first list is filled with car manufacturer"
I have ~80 manufacturers without China market I think, finally it may be ~100.
------------------------------------
I've spent else a bit time and now I'm knowing a bit more...
1. This bug isn't a "news". And I'm not the first person who has detected it.
2. On old version of VC there was a bug: Wizard supports file .CLW upto 64K. Not bigger.
Microsoft had fixed this bug, but unfortunatelly at "microsoft manner".
I've done some experiments and now I know:
1. Wizard can create a long .CLW. But wizard cannot read .CLW above certain size.
2. There are many types of resources in the .CLW. Wizard places all those types on the DIFFERENT stacks each type. Therefore I have no problem to add dialogs (currently I have 65 dialogs, they require a short space). But I have problem to add menu items (currently 1096).
|
|
|
|
|
I could be missing something obvious here, but how do you keep your application up to date? Cars and manufacturers come and go on a frequent basis. With every change you will be recompiling your resources and re-linking your application. That seems an odd and certainly unconventional way of doing it. ie. That's a lot of maintenance work. Just curious.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
hint: cheap labor.
Nihil obstat
|
|
|
|
|
Member 708172 wrote: This project operates with cars
Ok.
Member 708172 wrote: that are splitted by models.
That has nothing to do with cars. It has to do with design of the software.
And it is wrong.
Member 708172 wrote: No, you don't, but somehow you are sure that our users are not happy to navigate
through this menu.
I suspect however that your users do not care equally about every single model though.
So let us say hypothetically (and only that) that they do not want to use a dialog to select the car. Then you provide a way to dynamically add the cars that they do care about to the menu.
Presumably that is a feature that you have seen in other applications. Such as text processors.
Member 708172 wrote: Who from you solved a problem to combine over 1000 cars in an one project?
Not a project - a menu.
Member 708172 wrote: make your suggestions...
A dialog where they select make then model. Which is certainly what I have seen on every car app that I have seen. And if you want then you can let them add them to the menu.
Might note of course that make/model might not even be sufficient but trying to map variations after that to a menu would make it that much harder. But it is just another drop down in a dialog.
|
|
|
|
|
Consider the code below:
#include <stdio.h>
#include <stdlib.h>
#define FORCE_CAST(var, type) *(type*)&var
struct processor_status_register
{
unsigned int cwp:5;
unsigned int et:1;
unsigned int ps:1;
unsigned int s:1;
unsigned int pil:4;
unsigned int ef:1;
unsigned int ec:1;
unsigned int reserved:6;
unsigned int c:1;
unsigned int v:1;
unsigned int z:1;
unsigned int n:1;
unsigned int ver:4;
unsigned int impl:4;
}__attribute__ ((__packed__));
struct registers
{
unsigned long* registerSet;
unsigned long* globalRegisters;
unsigned long* cwptr;
unsigned long wim, tbr, y, pc, npc;
unsigned short registerWindows;
struct processor_status_register __attribute__ ((aligned (8))) psr;
}__attribute__ ((__packed__));
int getBit(unsigned long bitStream, int position)
{
int bit;
bit = (bitStream & (1 << position)) >> position;
return bit;
}
char* showBits(unsigned long bitStream, int startPosition, int endPosition)
{
char* bits = (char*)malloc(endPosition - startPosition + 2);
int bitIndex;
for(bitIndex = 0; bitIndex <= endPosition; bitIndex++)
bits[bitIndex] = (getBit(bitStream, endPosition - bitIndex)) ? '1' : '0';
bits[bitIndex] = '\0';
return bits;
}
int main()
{
struct registers sparcRegisters; short isLittleEndian;
unsigned long checkEndian = 0x00000001;
if(*((char*)(&checkEndian)))
{printf("Little Endian\n"); isLittleEndian = 1;} Endian architecture detected
else
{printf("Big Endian\n"); isLittleEndian = 0;} Endian architecture detected
unsigned long registerValue = 0xF30010A7;
unsigned long swappedRegisterValue = isLittleEndian ? registerValue :
__builtin_bswap32(registerValue);
sparcRegisters.psr = FORCE_CAST(swappedRegisterValue, struct
processor_status_register);
registerValue = isLittleEndian ? FORCE_CAST (sparcRegisters.psr,
unsigned long) : __builtin_bswap32(FORCE_CAST (sparcRegisters.psr,
unsigned long));
printf("\nPSR=0x%0X, IMPL=%u, VER=%u, CWP=%u\n", registerValue,
sparcRegisters.psr.impl, sparcRegisters.psr.ver,
sparcRegisters.psr.cwp);
printf("PSR=%s\n",showBits(registerValue, 0, 31));
sparcRegisters.psr.cwp = 7;
sparcRegisters.psr.et = 1;
sparcRegisters.psr.ps = 0;
sparcRegisters.psr.s = 1;
sparcRegisters.psr.pil = 0;
sparcRegisters.psr.ef = 0;
sparcRegisters.psr.ec = 0;
sparcRegisters.psr.reserved = 0;
sparcRegisters.psr.c = 0;
sparcRegisters.psr.v = 0;
sparcRegisters.psr.z = 0;
sparcRegisters.psr.n = 0;
sparcRegisters.psr.ver = 3;
sparcRegisters.psr.impl = 0xF;
registerValue = isLittleEndian ? FORCE_CAST (sparcRegisters.psr,
unsigned long) : __builtin_bswap32(FORCE_CAST (sparcRegisters.psr,
unsigned long));
printf("\nPSR=0x%0X, IMPL=%u, VER=%u, CWP=%u\n", registerValue,
sparcRegisters.psr.impl, sparcRegisters.psr.ver,
sparcRegisters.psr.cwp);
printf("PSR=%s\n\n",showBits(registerValue, 0, 31));
return 0;
}
//////////////////////////////////////////////////////////////////////////////
I have used gcc-4.7.2 on Solaris 10 on SPARC to compile the following
code to produce the Big-Endian output:
Big Endian
PSR=0xF30010A7, IMPL=3, VER=15, CWP=20
PSR=11110011000000000001000010100111
PSR=0x3F00003D, IMPL=15, VER=3, CWP=7
PSR=00111111000000000000000000111101
//////////////////////////////////////////////////////////////////////////////
I have used gcc-4.4 on Ubuntu-10.04 on Intel-x86 to compile the
following code to produce the Little-Endian output:
Little Endian
PSR=0xF30010A7, IMPL=15, VER=3, CWP=7
PSR=11110011000000000001000010100111
PSR=0xF30000A7, IMPL=15, VER=3, CWP=7
PSR=11110011000000000000000010100111
//////////////////////////////////////////////////////////////////////////////
While the later one is as expected, can anyone please explain the
Big-Endian counterpart? Considering the showBits() method to be
correct, how can PSR=0x3F00003D give rise to IMPL=15, VER=3, CWP=7
values? How is the bit-field is being arranged and interpreted in
memory on a Big-Endian system?
|
|
|
|
|
As far as I recall the bit fields in a structure are described in right to left order on x86. I cannot recall if this is true for Sparc also; it's been a while. However, the best way to check is to look at the compiler documentation: this is Microsoft's take on the issue[^].
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
The short answer is that bit-field allocation/alignment is pretty much totally at the mercy of the implementation, according to the standards.
In other words, the compiler writer can do almost anything she wants, as long as it's internally consistent.
Have fun!
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Have you noticed that the number of 1's in first PSR output is 11 while on the second case it is 12 ? How can bit reordering change number of 1's?
|
|
|
|
|
No idea.
Suggestion: write a little test that sets each bitfield in turn to all 1's, then dump PSR. That should tell you exactly where each one lives in each implementation.
Good hunting,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|